Messages in this thread |  | | Date | Mon, 28 Aug 2000 13:30:37 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [patch] getting rid of the Big Kernel Spinlock, 2.4.0-test7 |
| |
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/
|  |