==> Regarding Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix; Christoph Hellwig <[EMAIL PROTECTED]> 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 _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
