Re: [PATCH] 2.5: push BKL out of llseek

[Nigel Gamble]

On Thu, 31 Jan 2002, Martin Wirth wrote:
> A further note: Although the combilock shares some advantages with a
> spin-lock (no unnecessary scheduling for short time locking) it may
> behave like a semaphore on entry also if you call combi_spin_lock.
> For example
>
>        spin_lock(&slock);
>        combi_spin_lock(&clock);
>
> is a BUG because combi_spin_lock may sleep while holding slock!
>
> Would be nice if there were some comments.

Nice work!  This could turn out to be a useful tool for those of us
working on reliable low-latency kernels.  I certainly agree that it is a
much better solution than adaptive spinlocks (which dynamically decide
when to sleep) as the kernel programmer should always know whether a
spinlock or a sleep lock is more appropriate.

Unfortunately, as you point out, it's not as useful as it may first
appear in the short term, because last time I looked into the problem of
long-held spinlocks they were all nested under other spinlocks and/or
the BKL.

Nigel Gamble                                    [e-mail]
Mountain View, CA, USA.                         http://www.nrg.org/