Re: RT Mutex patch and tester [PREEMPT_RT]

[Esben Nielsen <simlo@phys.au.dk>]

On Sun, 22 Jan 2006, Bill Huey wrote:

> 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.

Sounds good. But someone might put it in...

> Remember, BKL is now preemptible so the place that it might sleep
> similar
> to the above would be in spinlock_t definitions.
I can't see that from how it works. It is explicitly made such that you
are allowed to use semaphores with BKL held - and such that the BKL is
released if you do.

> But BKL is held across schedules()s
> so that the BKL semantics are preserved.
Only for spinlock_t now rt_mutex operation, not for semaphore/mutex
operations.
> Contending under a priority inheritance
> operation isn't too much of a problem anyways since the use of it already
> makes that
> path indeterminant.
The problem is that you might hit BKL because of what some other low
priority  task does, thus making your RT code indeterministic.

> Even under contention, a higher priority task above A can still
> run since the kernel is preemptive now even when manipulating BKL.

No, A waits for BKL because it waits for B which waits for the BKL.

Esben
>
> 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/
>

-
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/