Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754875AbYJVI2z (ORCPT ); Wed, 22 Oct 2008 04:28:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754444AbYJVI2i (ORCPT ); Wed, 22 Oct 2008 04:28:38 -0400 Received: from ipmail01.adl6.internode.on.net ([203.16.214.146]:20989 "EHLO ipmail01.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753013AbYJVI2h (ORCPT ); Wed, 22 Oct 2008 04:28:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM8S9kh5LE2t/2dsb2JhbADCJoFr X-IronPort-AV: E=Sophos;i="4.33,463,1220193000"; d="scan'208";a="215852022" Date: Wed, 22 Oct 2008 19:28:29 +1100 From: Dave Chinner To: Alexander Beregalov Cc: lachlan@sgi.com, Christoph Hellwig , Arjan van de Ven , xfs@oss.sgi.com, linux-next@vger.kernel.org, LKML Subject: Re: BUG: sleeping function called from invalid context at kernel/rwsem.c:131 XFS? (was: Re: linux-next: Tree for October 17) Message-ID: <20081022082828.GN18495@disturbed> Mail-Followup-To: Alexander Beregalov , lachlan@sgi.com, Christoph Hellwig , Arjan van de Ven , xfs@oss.sgi.com, linux-next@vger.kernel.org, LKML References: <20081017203710.GA27187@infradead.org> <20081017135510.7127c4e7@infradead.org> <20081020163327.GA15651@infradead.org> <20081020223549.GA21152@disturbed> <20081022075838.GK18495@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1125 Lines: 30 On Wed, Oct 22, 2008 at 12:21:23PM +0400, Alexander Beregalov wrote: > > Ah, OK, I see the problem, though I don't understand why I'm not > > seeing the might_sleep() triggering all the time given that I always > > build with: > > > > $ grep SLEEP .config > > CONFIG_DEBUG_SPINLOCK_SLEEP=y > > > > Basically the above commit moved xfs_ilock() inside > > radix_tree_preload()/radix_tree_preload_end(), which means we are > > taking a rwsem() while we have an elevated preempt count. I'll > > get a patch out to fix it. > Could it cause the I/O dead lock or should I continue trying to reproduce it? The deadlock wouldn't be produced by the same thing that produced the sleeping-in-atomic warning. The missed unlock that I also fixed in the patch I just sent could possibly have caused that, but I'm just speculating on that... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- 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/