From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: [announce] vfs-scale git tree update Date: Thu, 13 Jan 2011 09:46:00 +0800 Message-ID: <1294883160.2757.2.camel@perseus> References: <20110107075831.GA14915@amd> <1294763679.2435.72.camel@doink> <1294768668.2435.177.camel@doink> <1294804776.2821.4.camel@perseus> <87aaj6u3oi.fsf@linux.vnet.ibm.com> <1294808464.2821.15.camel@perseus> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "Aneesh Kumar K. V" , aelder@sgi.com, Linus Torvalds , Nick Piggin , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Nick Piggin Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2011-01-13 at 11:58 +1100, Nick Piggin wrote: > On Wed, Jan 12, 2011 at 4:01 PM, Ian Kent wrote: > > On Wed, 2011-01-12 at 10:19 +0530, Aneesh Kumar K. V wrote: > >> for 9p I did the other way round. lookup now set the dentry op for both > >> negative and positive dentries and rest of the place we dropped > >> d_set_d_op (b8b80cf37c7f0e32729262f805bc0fa81c3e9d12 have the details) > > > > Sadly I can't do that. > > > > For now I need to avoid calls to ->d_revalidate() as much as possible to > > reduce a potential deadlock and have access to the flags of the negative > > dentry (during create) for the purpose of blocking concurrent walks. > > What prevents your d_revalidate from just checking for negative dentry? Whether the dentry is negative or not doesn't change the need to block walks which introduces the possibility of blocking while holding the parent i_mutex, since it can't be released in revalidate.