Re: [PATCH] sound_core.c: Remove BKL from soundcore_open

[Arjan van de Ven <arjan@infradead.org>]

On Sun, 11 Oct 2009 11:15:43 -0600
Jonathan Corbet <corbet@lwn.net> wrote:

> On Sun, 11 Oct 2009 09:20:15 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
> 
> > Changing the
> > BKL to a mutex is a real semantic change which requires a real
> > survey of the code affected.
> 
> One other aspect of this I forgot to mention...it's actually possible
> (if unlikely) that one of those lower-level open routines depends on
> the BKL's release-on-sleep semantics.  Swapping in a mutex would
> change that behavior, possibly resulting in deadlocks.
> 
> I think it was Alan who once pointed out that the BKL is badly
> misnamed.  It isn't really a lock, it's a modified execution
> environment designed to let naive kernel code think it's still running
> in a uniprocessor, no-preemption situation.  Replacing the BKL with a
> different lock changes that environment, so one has to be *really*
> careful about looking for any assumptions which may remain in the
> code.
> 

it's getting time though to bite the bullet and make it a real normal
mutex. Lockdep will then flag a bunch of sh*t we'll need to fix, but
without doing that we're never going to really make progress. 

The BKL has outlived its usefulness. Many of the things it used to
protect (device open, module load etc) no longer take the BKL since
quite a while, making the notion of "if you see the BKL you have a bug" 
more and more true.

Going from rather obscure semantics to more defined, and more
importantly, checkable-by-lockdep semantics is going to be a step
forward in this sense; while we can't check that it protects what it
should, we can at least start treating it like a real lock...


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org