From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtk@us.ibm.com (John T. Kohl) Subject: Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix Date: 09 Dec 2005 08:33:45 -0500 Message-ID: <6cd5k6xume.fsf@sumu.lexma.ibm.com> References: <1133547148.8976.25.camel@lade.trondhjem.org> <20051204125612.GA28229@infradead.org> <20051204125740.GB28229@infradead.org> <20051204171729.GA31111@infradead.org> <17302.157.540958.723305@segfault.boston.redhat.com> <20051206214033.GA31000@infradead.org> <1133968943.4581.22.camel@brilong-lnx> <43971FFF.2090900@us.ibm.com> <20051209121239.GA17898@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Brian Long , Jeff Moyer , autofs mailing list , wtaber@us.ibm.com, Trond Myklebust , linux-fsdevel , Ian Kent Return-path: Received: from e34.co.us.ibm.com ([32.97.110.152]:19690 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S1750846AbVLINeO (ORCPT ); Fri, 9 Dec 2005 08:34:14 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB9DY7Cj008667 for ; Fri, 9 Dec 2005 08:34:07 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB9DXN8R099100 for ; Fri, 9 Dec 2005 06:33:23 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jB9DY6tn001727 for ; Fri, 9 Dec 2005 06:34:07 -0700 To: Christoph Hellwig In-Reply-To: <20051209121239.GA17898@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org >>>>> "Christoph" == Christoph Hellwig writes: Christoph> On Wed, Dec 07, 2005 at 12:46:39PM -0500, Will Taber wrote: >> problem at hand. Anyway, with this information, is it appropriate for >> us to replace our calls to lookup_one_len with calls to path_walk or is >> that also forbidden? Christoph> path_walk and firends resolve a full path. As such they are Christoph> definitly not suitable for stackable filesystem, they are Christoph> intendeded only for implementating syscalls (and syscall-like Christoph> interfaces, e.g. some ioctls) path_lookup() takes a pathname and interprets it relative to cwd or root, so it's definitely not useful for stacking. But path_walk() takes a pathname fragment and an initialized nameidata (start point), so it *could* be used to resolve a single component, or multiple components. If lookup_one_len() is for use within the caller's file system only, and path_walk() is not suitable for stacking, then what calls *are* suitable for stacking file systems to use? We want to start with an existing (dentry,vfsmnt) and a pathname component, converting it to the (dentry,vfsmnt) of the result. -- John Kohl Senior Software Engineer - Rational Software - IBM Software Group Lexington, Massachusetts, USA jtk@us.ibm.com