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 10:20:10 -0500 Message-ID: <437DF12A.5050805@us.ibm.com> References: <20051116101740.GA9551@RAM> <1132159817.5720.33.camel@localhost> <1132192362.5720.163.camel@localhost> <437CD7D2.40003@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 e33.co.us.ibm.com ([32.97.110.151]:33704 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S1750848AbVKRPUQ (ORCPT ); Fri, 18 Nov 2005 10:20:16 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAIFKFqC030130 for ; Fri, 18 Nov 2005 10:20:15 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAIFLXLY075172 for ; Fri, 18 Nov 2005 08:21:33 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAIFKEuH013017 for ; Fri, 18 Nov 2005 08:20:15 -0700 To: Ian Kent In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Ian Kent wrote: > On Thu, 17 Nov 2005, William H. Taber wrote: > > Hi Taber, Hi, You can call me Will. Most everyone else does. :^) > >> >>Ian, >>I don't think that you can fix this in the autofs by tinkering with >>holding and releasing the parent i_sem. The reason for this is that you >> don't have any way of knowing if you hold that lock or not. The easy >>case is that nobody holds the lock. But if the lock is held you have no >>way to know that you are the person holding the lock and you cannot >>unlock someone elses lock without serious consequences. > > > Yes. I see. > > But let me make sure I understand what you are saying. > > The problem would be that if I release and then retake the lock for autofs > to do it thing there is a risk of opening the caller to the potential > races it is protecting itself from. > > Correct? > 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. Regards, Will