Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix

[Jeff Moyer <jmoyer@redhat.com>]

==> Regarding Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix; Christoph Hellwig <hch@infradead.org> adds:

hch> On Tue, Dec 06, 2005 at 04:20:29PM -0500, Jeff Moyer wrote: No, for
hch> current TOT that can't happen.  It could happen for older kernels but
hch> nothing is doing it in the tree anymore and if anything outside is
hch> 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.

hch> TOT = top of tree.

hch> To rephrease the above: With current mainline the nameidata argument
hch> is always valid when ->lookup or ->d_revalidate are called except when
hch> the filesystem uses lookup_one_len.  lookup_one_len is a helper for
hch> fileystem usage that is only valid to be used on the filesystems own
hch> 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?

hch> This out of tree module is wrong and always has been wrong.  Any
hch> actual breakage of such a module is expected.

Thanks for the clarification.  This was my interpretation, but I wanted to
be sure.

hch> Do you happen to know what module that is?

Well, the example originally posted was stubfs, which was purported to be a
sample fs used to show this problem.  Perhaps the original reporter can
tell us what other code does this.

-Jeff