From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Taber Subject: Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix Date: Fri, 02 Dec 2005 11:35:19 -0500 Message-ID: <439077C7.9050300@us.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Moyer , Trond Myklebust , Ram Pai , autofs mailing list , linux-fsdevel Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:32152 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S1750812AbVLBQfW (ORCPT ); Fri, 2 Dec 2005 11:35:22 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB2GZMmJ020161 for ; Fri, 2 Dec 2005 11:35:22 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB2GYlf6082688 for ; Fri, 2 Dec 2005 09:34:47 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jB2GZLBC029137 for ; Fri, 2 Dec 2005 09:35:22 -0700 To: Ian Kent In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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. Regards, Will Will