From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: [RFC PATCH]autofs4: hang and proposed fix Date: Sun, 4 Dec 2005 22:58:03 +0800 (WST) Message-ID: References: <438E0C66.6040607@us.ibm.com> <1133384015.8974.35.camel@lade.trondhjem.org> <438E1A05.7000308@us.ibm.com> <438F251B.7060602@us.ibm.com> <43906968.6080508@us.ibm.com> <1133547148.8976.25.camel@lade.trondhjem.org> <20051204125612.GA28229@infradead.org> <20051204125740.GB28229@infradead.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: autofs mailing list , Trond Myklebust , Will Taber , linux-fsdevel Return-path: To: Christoph Hellwig In-Reply-To: <20051204125740.GB28229@infradead.org> 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 Sun, 4 Dec 2005, Christoph Hellwig wrote: > On Sun, Dec 04, 2005 at 12:56:12PM +0000, Christoph Hellwig wrote: > > They are still NULL in exactly one case: lookup_one_len. Given the design > > of lookup_one_len we can't get at a nameidata there at all. > > Oh, forgot the most important bit here :) lookup_one_len is a library helper > never called by the VFS. autofs (v4 at least) doesn't use it so now always > get a nameidata. In fact if you look in -mm there's a patch from me that > makes use of that fact. > But Will is calling it in a something like a stacking context and autofs fails to handle it. Hence this discussion. Ian