From mboxrd@z Thu Jan 1 00:00:00 1970 From: "William H. Taber" Subject: Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix Date: Fri, 18 Nov 2005 12:12:02 -0500 Message-ID: <437E0B62.4000306@us.ibm.com> References: <20051116101740.GA9551@RAM> <1132159817.5720.33.camel@localhost> <1132192362.5720.163.camel@localhost> <437CD7D2.40003@us.ibm.com> <437DF12A.5050805@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ram Pai , autofs mailing list , linux-fsdevel Return-path: Received: from e4.ny.us.ibm.com ([32.97.182.144]:30930 "EHLO e4.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1030200AbVKRRMJ (ORCPT ); Fri, 18 Nov 2005 12:12:09 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAIHC4fr025288 for ; Fri, 18 Nov 2005 12:12:04 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAIHC4Xn121732 for ; Fri, 18 Nov 2005 12:12:04 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAIHC3tY013217 for ; Fri, 18 Nov 2005 12:12:04 -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, 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? 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 >