Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764381AbYARRc3 (ORCPT ); Fri, 18 Jan 2008 12:32:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1764317AbYARRcN (ORCPT ); Fri, 18 Jan 2008 12:32:13 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:42340 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764096AbYARRcL (ORCPT ); Fri, 18 Jan 2008 12:32:11 -0500 Date: Fri, 18 Jan 2008 09:30:20 -0800 (PST) From: Linus Torvalds To: Jan Kiszka cc: Steven Rostedt , Jiri Kosina , LKML , Andrew Morton , Alexey Dobriyan , Kirill Korotaev , Ingo Molnar Subject: Re: [PATCH] printk deadlocks if called with runqueue lock held In-Reply-To: <4790BDD1.40808@siemens.com> Message-ID: References: <4790BDD1.40808@siemens.com> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2036 Lines: 58 On Fri, 18 Jan 2008, Jan Kiszka wrote: > Steven Rostedt wrote: > ... > > @@ -978,7 +980,13 @@ void release_console_sem(void) > > console_locked = 0; > > up(&console_sem); > > Hmm, just looking at this fragment: Doesn't up() include the risk of > running onto the runqueue lock as well? In theory yes. I suspect it would never ever be a problem in practice (the case we care about is running with interrupts disabled, and we got it with down_trylock()), so as this is only about essentially custon debug or oops things anyway, it's probably not worth fixing. That said, you're definitely right in theory. But *IF* we want to fix the almost certainly purely theoretical problem, it would be possible but fairly ugly. We'd need to (a) make it a mutex rather than a semaphore (which is definitely not the ugly part), and then - the ugly part - (b) expose a whole new mutex interface: an enhanched version of "mutex_trylock()" that *also* keeps the mutex spinlock locked, and then instead of using "mutex_unlock()" we'd use a special "mutex_unlock_atomic()" that knows the spinlock was held over the whole time. So it would then use something like if (mutex_trylock_atomic(..)) { mutex_unlock_atomic(..); } and that would work out ok. It's likely not that hard, and in fact this may be why "console_sem" was never converted to a mutex: I think Ingo tried, but it didn't work right with debugging enabled, and I can well imagine that it was all due to this issue. But if we do those _atomic() versions, we'd probably fix that problem. So maybe the "ugly new interface" would actually be a cleanup in the long run, by possibly fixing the fact that things just *happened* to work with semaphores because they didn't do the fancy debug version.. Ingo? Linus -- 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/