From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: [RFC PATCH]autofs4: hang and proposed fix Date: Sat, 3 Dec 2005 01:36:35 +0800 (WST) Message-ID: References: <20051116101740.GA9551@RAM> <17292.64892.680738.833917@segfault.boston.redhat.com> <1133315771.8978.65.camel@lade.trondhjem.org> <438E0C66.6040607@us.ibm.com> <1133384015.8974.35.camel@lade.trondhjem.org> <438E1A05.7000308@us.ibm.com> <438F251B.7060602@us.ibm.com> <17296.28812.390586.101214@segfault.boston.redhat.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: autofs mailing list , linux-fsdevel , "William H. Taber" , Trond Myklebust Return-path: To: Jeff Moyer In-Reply-To: <17296.28812.390586.101214@segfault.boston.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2 Dec 2005, Jeff Moyer wrote: > ==> Regarding Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix; Ian Kent adds: > > raven> On Thu, 1 Dec 2005, William H. Taber wrote: > >> > So the question is, can anyone provide an example of a path that, upon > >> > calling autofs revalidate or lookup with the i_sem held, not be the > >> path > that aquired it? > > raven> So still no counter example! > > >> Any other process calling lookup_one_len on a file in /net. > > raven> I'm afraid this is not an example it's an assertion. "Any other > raven> process" is a little broad I think. You'll need to be more > raven> specific. > > Well, I think we've determined that the reported problem doesn't happen > with any in-tree callers. The question, then, is do you want to fix the > locking problem? Two approaches were presented in this thread. I don't > really like the idea of the hack used by devfs, since it relies on implicit > semantics. I haven't given much thought to the second approach, though > (are we sure it can be made to work?). It may require a good deal of > effort, but if it makes things work properly, it's worth considering. I'm > just not sure where it sits in the list of priorities, as I know you've got > a lot on your plate, Ian. It appears to me that the unhashed directory approach proposed by Will does not account for directories that exist but don't have current mounts. I will re-read the posts, I expect I missed something, and give it more thought. Ian