Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761375AbYCXSAA (ORCPT ); Mon, 24 Mar 2008 14:00:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755758AbYCXR7x (ORCPT ); Mon, 24 Mar 2008 13:59:53 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:50076 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753694AbYCXR7w (ORCPT ); Mon, 24 Mar 2008 13:59:52 -0400 Date: Mon, 24 Mar 2008 10:58:50 -0700 (PDT) From: Linus Torvalds To: Peter Zijlstra cc: Andrew Morton , Ingo Molnar , Thomas Gleixner , Marcin Slusarz , LKML Subject: Re: [PATCH 0/2] printk vs rq->lock and xtime lock In-Reply-To: <20080324122424.671168000@chello.nl> Message-ID: References: <20080324122424.671168000@chello.nl> 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: 1018 Lines: 28 On Mon, 24 Mar 2008, Peter Zijlstra wrote: > > As to the regression reported by Marcin; what happens is that we invoke > printk() while holding the xtime lock for writing. printk() will call > wake_up_klogd() which tries to enqueue klogd on some rq. > > The known deadlock here is calling printk() while holding rq->lock, which > would then try to recusively lock the rq again when trying to wake klogd. Ok. Right now, however, I think that for 2.6.25 I'll just remove the printk. And for the long haul, I really don't think the solution is "printk_nowakup()", because this is going to happen again when somebody doesn't realize the code is called with the rq lock held, and it's going to be a bitch to debug. I just don't think this is maintainable. 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/