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 13:33:50 -0500 Message-ID: <4390938E.3050502@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.28812.390586.101214@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 e3.ny.us.ibm.com ([32.97.182.143]:19847 "EHLO e3.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1750852AbVLBSd7 (ORCPT ); Fri, 2 Dec 2005 13:33:59 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB2IXsr4010369 for ; Fri, 2 Dec 2005 13:33:54 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB2IXs1U123812 for ; Fri, 2 Dec 2005 13:33:54 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jB2IXrrU031647 for ; Fri, 2 Dec 2005 13:33:53 -0500 To: Ian Kent In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Ian Kent wrote: > On Fri, 2 Dec 2005, Jeff Moyer wrote: > > >>==> Regarding Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix; Ian Kent adds: >> >>raven> On Thu, 1 Dec 2005, William H. Taber wrote: >> >>>>>So the question is, can anyone provide an example of a path that, upon >>>>>calling autofs revalidate or lookup with the i_sem held, not be the >>>> >>>>path > that aquired it? >> >>raven> So still no counter example! >> >> >>>>Any other process calling lookup_one_len on a file in /net. >> >>raven> I'm afraid this is not an example it's an assertion. "Any other >>raven> process" is a little broad I think. You'll need to be more >>raven> specific. >> >>Well, I think we've determined that the reported problem doesn't happen >>with any in-tree callers. The question, then, is do you want to fix the >>locking problem? Two approaches were presented in this thread. I don't >>really like the idea of the hack used by devfs, since it relies on implicit >>semantics. I haven't given much thought to the second approach, though >>(are we sure it can be made to work?). It may require a good deal of >>effort, but if it makes things work properly, it's worth considering. I'm >>just not sure where it sits in the list of priorities, as I know you've got >>a lot on your plate, Ian. > > > It appears to me that the unhashed directory approach proposed by Will > does not account for directories that exist but don't have current mounts. > > I will re-read the posts, I expect I missed something, and give it more > thought. > It doesn't consider that case. You had mentioned it but I had forgotten. Will