Re: [patch] getting rid of the Big Kernel Spinlock, 2.4.0-test7

From: Alexander Viro (
Date: Mon Aug 28 2000 - 12:30:37 EST

On Mon, 28 Aug 2000, Ingo Molnar wrote:

> On Mon, 28 Aug 2000, Alexander Viro wrote:
> > Umm... I would not do that. Reason: right now BKL can be acquired
> > while we are holding a spinlock. It's a bad idea, but it's possible.
> hm, shouldnt we fix those places? It sounds extremely dangerous to get the
> BKL with a spinlock held.

Probably... ISTR that there was a long-living spinlock somewhere in mm/*.c,
but you are more familiar with that area...

> > With your change it becomes deadly. [...]
> agreed, i missed that. Is there any core kernel code that does this? [the
> VFS? :-)]

I can't think of any places where we actually did that, but... it's a
pretty weak warranty ;-/ I've seen a lot of amazingly dumb things
happening and "nobody sane would do that" doesn't replace the analysis -
there's always somebody who wanted to be smart.

VFS _generally_ releases the spinlocks before calling methods (and rules
are described in Documentation/filesystems/Locking), so I think that it's
OK (very easy to verify, anyway), but VM can be scarier and I don't want
even think about drivers... Network stuff seems to be relatively BKL-free.
Architecture-dependent stuff... Hell knows.

> > Another reason: currently BKL can be taken in the middle of operations
> > on per-CPU data. It will not block, so nothing will get that CPU while
> > we are in lock_kernel(). Not true with your patch.
> oops, another thinko indeed. Sigh. Are there any prominent examples of
> this? I think we want to fix these.

We probably want, but that will require catching them. It should be easier
now (in almost all cases we have a chance to block very soon after the
lock_kernel(), so areas to look into shouldn't be that large), but I'm not
too happy about making the change without doing their analysis - it will
be needed anyway and doing it now over the whole tree would be easier than
doing it piece-wise later.

Essentially, you are adding tons of scheduling points all over the tree
and it's not a thing to make blindly...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST