Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756414AbZJKRQF (ORCPT ); Sun, 11 Oct 2009 13:16:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755812AbZJKRQD (ORCPT ); Sun, 11 Oct 2009 13:16:03 -0400 Received: from vena.lwn.net ([206.168.112.25]:40302 "EHLO vena.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755540AbZJKRQB (ORCPT ); Sun, 11 Oct 2009 13:16:01 -0400 Date: Sun, 11 Oct 2009 11:15:43 -0600 From: Jonathan Corbet To: Jonathan Corbet Cc: John Kacur , Alan Cox , linux-kernel@vger.kernel.org, Thomas Gleixner , Peter Zijlstra , Frederic Weisbecker , Christoph Hellwig , Andrew Morton , Vincent^M^J Sanders , Ingo Molnar Subject: Re: [PATCH] sound_core.c: Remove BKL from soundcore_open Message-ID: <20091011111543.1cbb9a0e@tpl.lwn.net> In-Reply-To: <20091011092015.37a69847@bike.lwn.net> References: <20091011004219.74c30f67@lxorguk.ukuu.org.uk> <20091011092015.37a69847@bike.lwn.net> Organization: LWN.net X-Mailer: Claws Mail 3.7.2 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1205 Lines: 28 On Sun, 11 Oct 2009 09:20:15 -0600 Jonathan Corbet 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. That's why BKL-hunting is harder than it looks - and why the BKL has hung around for all these years. jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/