From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix Date: Wed, 16 Nov 2005 11:51:12 -0800 Message-ID: <1132170672.5720.78.camel@localhost> References: <20051116101740.GA9551@RAM> <17275.20160.12805.536289@segfault.boston.redhat.com> <1132160404.5720.44.camel@localhost> <17275.31136.794385.872761@segfault.boston.redhat.com> <437B8750.9030901@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: jmoyer@redhat.com, autofs@linux.kernel.org, linux-fsdevel@vger.kernel.org Return-path: Received: from e1.ny.us.ibm.com ([32.97.182.141]:23683 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1030445AbVKPTvP (ORCPT ); Wed, 16 Nov 2005 14:51:15 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAGJpEpS009751 for ; Wed, 16 Nov 2005 14:51:14 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAGJpE9N027466 for ; Wed, 16 Nov 2005 14:51:14 -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 jAGJpEFD019475 for ; Wed, 16 Nov 2005 14:51:14 -0500 To: William H Taber In-Reply-To: <437B8750.9030901@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-11-16 at 11:24, William H. Taber wrote: > Jeff Moyer wrote: > > ==> Regarding Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix; Ram Pai adds: > > > > > I've been trying to reproduce this using sleeps in the user space daemon, > > and I can't. Can you post your test code so that I'm not guessing at > > what's going on? For example, one thing that's unclear is how you are > > stuffing stubfs in between the vfs and autofs. > > > > -Jeff > > - > The stubfs is just a test filesystem I wrote to reproduce this problem. > It doesn't sit between the vfs and autofs. What it does is to do a > lookup on /net and save the inode for it. Then it gets the i_sem on > /net and calls lookup_one_len on a given hostname. The second time in > it omits the lookup (it already has the inode for /net) and down on the > i_sem lock and then calls lookup_one_len. It has some of it's own > locking to get properly synchronized to force the race condition. What > happens is that both processes are waiting on i_sem for /net. The first > one gets it, and calls into the autofs which creates the new dentry, > starts the automount deamon, and waits for the mount to complete. Since > the second lookup is already queued on the i_sem, it get's in second, > finds the dentry, calls revalidate which waits for the mount to complete > without releasing i_sem. This of course prevents the automounter from > completing the mount. > > Does this clarify? here is the pointer to the patch that applies and compiles on 2.6.15-rc1. http://www.sudhaa.com/~ram/readahead/stubfs.patch you will have to set up /net/ram as the automounter location. That string is hardcoded. Maybe you can change that string to your environment. And you can modify to it make it a module. the instructions on how to reproduce is there in fs/stubfs/stub.c line number 129 roughly. This GPL code is for testing purpose only, RP > Will Taber