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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST