Cc: Alan Cox <alan@...>, Andi Kleen <andi@...>, <linux-kernel@...>, Andrew Morton <akpm@...>, Peter Zijlstra <a.p.zijlstra@...>, Thomas Gleixner <tglx@...>, Alexander Viro <viro@...>
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
--
