linux-kernel - Re: [announce] "kill the Big Kernel Lock (BKL)" tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 15 May 2008 10:02:11 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alexander Viro <viro@....linux.org.uk>
Subject: Re: [announce] "kill the Big Kernel Lock (BKL)" tree

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Wed, 14 May 2008, Alan Cox wrote:
> > 
> > That in itself is a problem Ingo's stuff won't help with: We have 
> > lots of "magic" accidental, undocumented and pot luck BKL locking 
> > semantics between subsystems that are not even visible.
> 
> The good news is that I suspect they are going away. It probably is 
> mainly tty and /proc by now, and /proc is pretty close to done.
> 
> It's hard to have too many inter-module dependencies when most of the 
> core modules no longer even take the kernel lock any more.

yeah. And Alan has a good point: there _is_ lots of magic stuff 
happening below the BKL. One of them are the BKL <-> other lock 
dependencies. My stuff helps with mapping that part of the magic: it 
turns the BKL into an ordinary mutex and thus integrates it into 
lockdep's existing dependency validation machinery.

In other words: this stuff makes BKL validation _stronger_, not weaker, 
and hence it ultimately helps its mapping and elimination. It turns the 
"magic" into something more concrete.

It might not help with other magic directly - but it helps indirectly, 
because now the "magic" has shrunk, so there's more attention and more 
resources available to fix it in the places where the magic hurts. (And 
suggestions are welcome for more debug helpers to make more magic more 
visible.)

Whenever someone narrows the BKL's scope, that will always have to be 
done carefully - and that's true of any other lock. This patchset 
(except perhaps the boot bits) does not narrow the BKL's scope.

It will still be no doubt a tough job (reducing/changing locking of 
_any_ locked path is a tough job), but it will now fit into our existing 
practices much better and we'll get various reminders from lockdep and 
the other debug helpers when we forgot about some detail.

Before this there was almost zero feedback from the kernel when 
something around the BKL broke: pretty much the only remainder we had 
from incorrect BKL elimination were subtle breakages.

And my personal experience might matter as well: before this i never 
dared to touch BKL code. I once removed _all_ BKL locking from all the 
kernel _by accident_ [i typoed a single line in lib/smp_lock.c] and ran 
it on my main desktop for about a day and never noticed a thing - until 
a few weird TTY messages popped up in the syslog...

But with this scheme, i felt _much_ more secure about touching BKL code, 
and kicking the BKL from the scheduler was pure joy i have to say. (even 
though it will of course remain in the upstream scheduler until we are 
reasonably sure about the stability of this whole kill-the-BKL approach)

I'm sure other subsystem maintainers will have a similar experience.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/