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, 19 Nov 2005 09:40:36 +0800 (WST) Message-ID: 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; charset=US-ASCII Cc: Ram Pai , autofs mailing list , linux-fsdevel Return-path: Received: from wombat.indigo.net.au ([202.0.185.19]:5900 "EHLO wombat.indigo.net.au") by vger.kernel.org with ESMTP id S1161127AbVKSBlV (ORCPT ); Fri, 18 Nov 2005 20:41:21 -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, 18 Nov 2005, 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. :^) Ha. It's probably wearing a bit thin for me to say I'm new here but my patch is quite small and I've got a lot to learn and I'm lovin' it. > 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? Maybe. See next post. Ian