From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932870Ab1ALEl2 (ORCPT ); Tue, 11 Jan 2011 23:41:28 -0500 Received: from out1.smtp.messagingengine.com ([66.111.4.25]:40503 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932791Ab1ALEl0 (ORCPT ); Tue, 11 Jan 2011 23:41:26 -0500 X-Sasl-enc: vs5iKtR2a9Zi6e3vwInKtARNgyeBivLnGBdHlKWZ94MM 1294807285 Subject: Re: [announce] vfs-scale git tree update From: Ian Kent To: Linus Torvalds Cc: aelder@sgi.com, Nick Piggin , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: <20110107075831.GA14915@amd> <1294763679.2435.72.camel@doink> <1294768668.2435.177.camel@doink> <1294804776.2821.4.camel@perseus> Content-Type: text/plain; charset="UTF-8" Date: Wed, 12 Jan 2011 12:41:19 +0800 Message-ID: <1294807279.2821.9.camel@perseus> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2011-01-11 at 20:06 -0800, Linus Torvalds wrote: > On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent wrote: > > > > Isn't the parent i_mutex held during mkdir()? > > Yes, but a lookup that hits in the dentry cache won't actually take > the parent mutex. > > So as far as I can tell, doing the "d_add()" before setting d_op can > result in another CPU coming in and seeing the newly added dentry > before d_op has actually been initialized. Exactly because it will do > the dentry lookup without holding any mutex. > > Of course, it's a very small window, so it probably doesn't matter in practice. > > >> Looking at it quickly, I don't think that would matter for > >> the case at hand. I.e., that might be safer but it doesn't > >> address the fact that these fields are getting initialized > >> multiple times. > > > > Yeah, a hangover from changes done over time. > > Not setting the dentry op in ->lookup() should fix this. > > Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()? > > (That code is a bit scary, though - it explicitly makes it a negative > dentry with a d_instantiate(dentry, NULL), and then hides the inode > information away separately. Scary scary) Yeah, but the expire to mount races with autofs are difficult to handle and this approach has worked well under heavy stress testing. It's true that this would almost certainly be bad for a file system that supported a full range of functionality but that's not so for autofs. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html