From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix Date: Sat, 3 Dec 2005 01:11:37 +0800 (WST) Message-ID: References: <20051116101740.GA9551@RAM> <17292.64892.680738.833917@segfault.boston.redhat.com> <1133315771.8978.65.camel@lade.trondhjem.org> <438E0C66.6040607@us.ibm.com> <1133384015.8974.35.camel@lade.trondhjem.org> <438E1A05.7000308@us.ibm.com> <438F251B.7060602@us.ibm.com> <17296.21777.592381.958840@segfault.boston.redhat.com> <439077C7.9050300@us.ibm.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Jeff Moyer , Trond Myklebust , Ram Pai , autofs mailing list , linux-fsdevel Return-path: Received: from wombat.indigo.net.au ([202.0.185.19]:58632 "EHLO wombat.indigo.net.au") by vger.kernel.org with ESMTP id S1750717AbVLBRM0 (ORCPT ); Fri, 2 Dec 2005 12:12:26 -0500 To: Will Taber In-Reply-To: <439077C7.9050300@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2 Dec 2005, Will Taber wrote: > Ian Kent wrote: > > > > > Good call. A single example is sufficient to refute my assertion. > > > > But to focus the discussion, the goal is to identify that the calling > > process is the one that holds the semaphore to justify releasing it. For > > lookup it's easy as it's always called with it held. lookup_hash will always > > call revalidate or lookup with the nameidata struct NULL and so can be used > > to identify the semaphore ownership similar to the devfs code Will > > mentioned. I don't think the other tests there are relevant to autofs. The > > patch will require some rework but still the same general idea. > > > > Can you think of an example code path where __lookup_hash is called with a > > non null nameidata struct which leads to autofs4 revalidate or lookup. > > > > It looks as though __lookup_hash is called from open_namei with the lock held > and a nameidata structure. It also looks as though LOOKUP_OPEN is set in the > nameidata->flags so you should be able to identify this case. No, that's not > because lookup_open does a path_walk to get the parent without the lock. So > it looks as though if you have a nameidata structure and the flags have > LOOKUP_OPEN and LOOKUP_CREATE set but not LOOKUP_PARENT, then you are holding > the i_sem lock. The devfs code ignores LOOKUP_OPEN. I have to go right now > and I am not sure if the checks are equivalent so I will leave that as an > exercise for the reader. The create case is not used by autofs. Shouldn't need to be considered. Ian