From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix Date: Fri, 18 Nov 2005 10:57:45 -0800 Message-ID: <1132340265.5720.191.camel@localhost> References: <20051116101740.GA9551@RAM> <1132159817.5720.33.camel@localhost> <1132192362.5720.163.camel@localhost> <437CD7D2.40003@us.ibm.com> <437DF12A.5050805@us.ibm.com> <437E0B62.4000306@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Ian Kent , autofs mailing list , linux-fsdevel Return-path: Received: from e1.ny.us.ibm.com ([32.97.182.141]:20674 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1161122AbVKRS5v (ORCPT ); Fri, 18 Nov 2005 13:57:51 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAIIvlNu008424 for ; Fri, 18 Nov 2005 13:57:47 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAIIvlma120186 for ; Fri, 18 Nov 2005 13:57:47 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAIIvk33020136 for ; Fri, 18 Nov 2005 13:57:47 -0500 To: William H Taber In-Reply-To: <437E0B62.4000306@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2005-11-18 at 09:12, William H. Taber wrote: > Ian Kent wrote: > > On Fri, 18 Nov 2005, William H. Taber wrote: > >> > >>No, it is actually a little more subtle than that. The problem is that since > >>you can be called from two code paths, one of which get's the lock and one of > >>them doesn't, you are stuck if you find that the lock is held because you > >>don't know who holds it. The danger is that some innocent third party is > >>holding the lock and counting on being protected by it. If you release the > >>lock, then you can be creating the potential for a race in their code and > >>there would be no way to detect it. Their code path would look correct > >>because it is. Not only that but the lock itself could get confused because > >>it would have more unlocks than locks, because presumably the process that > >>thinks it has the lock would eventually unlock as well. I don't know how the > >>semaphores are implemented on all architectures so I don't know if that would > >>be an actual problem or not but it I would be surprised if they all handled > >>that case gracefully. > > > > > > Yes. Thinking about it I hadn't considered the third process. > > > > How can we get advice on this? > > > > Ian > > > Hey, I'm new here. I came here looking for advice. :^) > However, if there is no way to fix this in the autofs code then the only > alternative is to fix the locking in the VFS. So VFS folks, which is > the better solution. Should all callers to d_revalidate get the > parent's i_sem lock or should d_revalidate never be called with the > parent i_sem lock and so we need to change lookup_one_len so that it > does not expect the parent i_sem lock to be held? I think the problem is with cached_lookup(). It is the only place which calls ->revalidate() holding the parent's inode-semaphore AFAICT. note: cached_lookup() is only called from __lookup_hash() and __lookup_hash() is always called holding the semaphore. VFS experts agree? RP > > Will Taber > > > - > > 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 > > >