Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932079AbZJKMrQ (ORCPT ); Sun, 11 Oct 2009 08:47:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754598AbZJKMrO (ORCPT ); Sun, 11 Oct 2009 08:47:14 -0400 Received: from verein.lst.de ([213.95.11.210]:40308 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754570AbZJKMrN (ORCPT ); Sun, 11 Oct 2009 08:47:13 -0400 Date: Sun, 11 Oct 2009 14:46:16 +0200 From: Christoph Hellwig To: John Kacur Cc: linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, Thomas Gleixner , Peter Zijlstra Subject: Re: [xfs-masters] INFO: possible circular locking dependency detected Message-ID: <20091011124616.GA4081@lst.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Score: -0.001 () BAYES_44 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 749 Lines: 15 This has been around for a long time, the VM calls into fput and thus ->release with the mmap_sem held, which makes it really hard for a filesystem to avoid a lock inversion if it uses a lock both in ->release and the I/O path. I have a workaround for this to only acquire the XFS iolock with a trylock in the release path and leave cleaning up stale preallocations until the final iput. It's not pretty, but given that we're unlikely to see the VM fixed I might aswell finally send it for inclusion. -- 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/