From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Mon, 11 Oct 2010 08:13:27 +0000 Subject: Re: [patch 1/2] OSS: soundcard: locking bug in sound_ioctl() Message-Id: <201010111013.28952.arnd@arndb.de> List-Id: References: <20101010173352.GB5851@bicker> <201010102039.34858.arnd@arndb.de> In-Reply-To: <201010102039.34858.arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Dan Carpenter Cc: Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org, linux-sparse@vger.kernel.org, Josh Triplett On Sunday 10 October 2010 20:39:34 Arnd Bergmann wrote: > On Sunday 10 October 2010 19:33:52 Dan Carpenter wrote: > > We shouldn't return directly here because we're still holding the > > &soundcard_mutex. > > > > This bug goes all the way back to the start of git. It's strange that > > no one has complained about it as a runtime bug. > > > > CC: stable@kernel.org > > Signed-off-by: Dan Carpenter > > It was only recently converted to a mutex from the BKL, which is much > more friendly to misusage because it is automatically released when > the kernel sleeps or when the program exits. > > The behavior was already broken with the BKL but the problem was far > less visible. I fear we might be seeing more of these as fallout from > the BKL removal. Sparse should be able to detect most of these cases > though, so maybe we can look more carefully for them. Hmm, actually sparse does *not* warn about sound_ioctl returning in different lock contexts. Sparse developers: is there a known limitation in sparse for this? I expected to see context warnings because sound_ioctl normally releases soundcard_mutex (previously lock_kernel) in some cases returns while holding the lock. Arnd