Re: [PATCH] vfs: automount should ignore LOOKUP_FOLLOW

[Ian Kent <raven@themaw.net>]

On Thu, 2011-09-08 at 10:42 -0700, Linus Torvalds wrote:
> On Thu, Sep 8, 2011 at 6:38 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > Yes, 2.6.38 and later kernels do trigger on stat(2) but not on lstat(2).
> >
> > My question is this:  does this behavior improve anything compared to
> > kernels before 2.6.38?  Because I don't see that it does, in fact it's
> > just causing regressions.
> >
> > You say it's a step in the right direction but I don't see why.  Either
> > we want stat *and* lstat to both be correct and trigger the automount or
> > we are satisfied with the incorrect but well established practice of not
> > triggering on (l)stat.
> >
> > The middle ground makes no sense IMO, there's nothing gained by the
> > differentiated behavior based on LOOKUP_FOLLOW.
> >
> > Can you explain why it's better if stat() tiggers automounts and gives a
> > correct result but lstat() doesn't?
> 
> I have to say that this is a very cogent question.
> 
> The one thing I've not seen in the thread yet is a description of the
> failure. What does the regression look like? Just "very slow 'ls' with
> some versions of 'ls'" or what?

The problem that is seen is everything in a directory being mounted upon
listing the directory. This isn't really a problem for small automount
maps but maps with more than a few dozen entries start becoming
problematic and a few hundred entries or more (quite common in many
environments) is an obvious nightmare.

Clearly this is a problem that I have introduced by the idea of the
"browse" option of autofs, whereby the potential automount points of an
indirect automount are visible within the automount managed directory
but it also applies to NFS crossing mount points (since those mount
point directories must also pre-exist).

Note that this isn't as problem if the "browse" option isn't used since
we just se an empty directory and specific access to a path causes only
those mounts to occur. But Solaris has been able to do this for years
now so it is expected by the user community.

> 
> I'm inclined to apply the patch as a regression fix, but I'll let this
> thread try to convince me for another day..

I have to agree, although it would be good to get some input from other
subsystem maintainers.

Ian