linux-kernel - Re: [PATCH] sound_core.c: Remove BKL from soundcore

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]

Message-ID: <20091011103755.649f5ae1@infradead.org>
Date:	Sun, 11 Oct 2009 10:37:55 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Jonathan Corbet <corbet@....net>
Cc:	Jonathan Corbet <corbet@....net>, John Kacur <jkacur@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vincent^M^J Sanders <vince@...tec.co.uk>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sound_core.c: Remove BKL from soundcore_open

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

> On Sun, 11 Oct 2009 09:20:15 -0600
> Jonathan Corbet <corbet@....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
--
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/