From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix Date: Tue, 6 Dec 2005 21:40:33 +0000 Message-ID: <20051206214033.GA31000@infradead.org> References: <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> <20051204171729.GA31111@infradead.org> <17302.157.540958.723305@segfault.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Ian Kent , Trond Myklebust , Will Taber , Ram Pai , autofs mailing list , linux-fsdevel Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:41346 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S932641AbVLFVky (ORCPT ); Tue, 6 Dec 2005 16:40:54 -0500 To: Jeff Moyer Content-Disposition: inline In-Reply-To: <17302.157.540958.723305@segfault.boston.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Dec 06, 2005 at 04:20:29PM -0500, Jeff Moyer wrote: > hch> No, for current TOT that can't happen. It could happen for older > hch> kernels but nothing is doing it in the tree anymore and if anything > hch> outside is doing it it's fundamentally broken. > > This is a bit unclear to me. What do you mean when you refer to "it" and > "that" above? Oh, and TOT is a TLA I haven't run across before. TOT = top of tree. To rephrease the above: With current mainline the nameidata argument is always valid when ->lookup or ->d_revalidate are called except when the filesystem uses lookup_one_len. lookup_one_len is a helper for fileystem usage that is only valid to be used on the filesystems own trees. > We know that there is at least one out of tree module that calls > lookup_one_len, and ends up in the autofs4 revalidate code without the > valid nameidata structure. In this case, with your patch, wouldn't we > blindly dereference the structure and cause an oops? If so, who is at > fault? This out of tree module is wrong and always has been wrong. Any actual breakage of such a module is expected. Do you happen to know what module that is?