Re: RT Mutex patch and tester [PREEMPT_RT]

[Bill Huey (hui) <billh@gnuppy.monkey.org>]

On Mon, Jan 23, 2006 at 01:20:12AM +0100, Esben Nielsen wrote:
> Here is the problem:
> 
> Task B (non-RT) takes BKL. It then takes mutex 1. Then B
> tries to lock mutex 2, which is owned by task C. B goes blocks and releases the
> BKL. Our RT task A comes along and tries to get 1. It boosts task B
> which boosts task C which releases mutex 2. Now B can continue? No, it has
> to reaquire BKL! The netto effect is that our RT task A waits for BKL to
> be released without ever calling into a module using BKL. But just because
> somebody in some non-RT code called into a module otherwise considered
> safe for RT usage with BKL held, A must wait on BKL!

True, that's major suckage, but I can't name a single place in the kernel that
does that. Remember, BKL is now preemptible so the place that it might sleep similar 
to the above would be in spinlock_t definitions. But BKL is held across schedules()s
so that the BKL semantics are preserved. Contending under a priority inheritance
operation isn't too much of a problem anyways since the use of it already makes that
path indeterminant. Even under contention, a higher priority task above A can still
run since the kernel is preemptive now even when manipulating BKL.

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/