From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH 3/3] nfs: use ->mmap_prepare() to avoid an AB-BA deadlock Date: Wed, 14 Nov 2007 22:31:45 +0100 Message-ID: <1195075905.22457.3.camel@lappy> References: <20071114200136.009242000@chello.nl> <20071114201528.514434000@chello.nl> <20071114212246.GA31048@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, Linus Torvalds , Andrew Morton , Trond Myklebust , Hugh Dickins To: Nick Piggin Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:36754 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753174AbXKNVdA (ORCPT ); Wed, 14 Nov 2007 16:33:00 -0500 In-Reply-To: <20071114212246.GA31048@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2007-11-14 at 22:22 +0100, Nick Piggin wrote: > On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote: > > Normal locking order is: > > > > i_mutex > > mmap_sem > > > > However NFS's ->mmap hook, which is called under mmap_sem, can take i_mutex. > > Avoid this potential deadlock by doing the work that requires i_mutex from > > the new ->mmap_prepare(). > > > > [ Is this sufficient, or does it introduce a race? ] > > Seems like an OK patchset in my opinion. I don't know much about NFS > unfortunately, but I wonder what prevents the condition fixed by > nfs_revalidate_mapping from happening again while the mmap is active...? As the changelog might have suggested, I'm not overly sure of the nfs requirements myself. I think it just does a best effort at getting the pages coherent with other clients, and then hopes for the best. I'll let Trond enlighten us further before I make an utter fool of myself :-)