Re: [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc.

[Ian Kent <raven@themaw.net>]

On Thu, 2011-09-22 at 18:04 -0700, Linus Torvalds wrote:
> On Thu, Sep 22, 2011 at 5:56 PM, Myklebust, Trond
> <Trond.Myklebust@netapp.com> wrote:
> >
> > Your assumption is that in the majority of cases, we do _not_ want to
> > automount the final directory unless we know that we are expecting a
> > directory.
> 
> Umm. That is the assumption yes, BUT THAT IS ALSO THE CURRENT STATE.

With the patch that Miklos posted, yes.

But the other users of the vfs-automount didn't behave this way before
the vfs-automount changes.

> 
> So it's more than an assumption. It's a fact.

For autofs itself, yes.

> 
> So when you call it "assumption", you are basically ignoring and
> trying to belittle current reality. Why?

Lets take a step back and re-examine what started this.

That is the semantic change automounting LOOKUP_FOLLOW path walks, aka.
stat and related system calls which Miklos wanted to change back.

Unfortunately, the reality is that most of the time (almost always
anyway) that is what should be done. The exceptions are such things as
long listing directory contents where we would also like stat to cause
automounting but cannot because it causes users to complain about lots
of mounts being triggered. Contrast that with the behavior of find(1)
where users sometimes don't want a bunch of mounts done but, in this
case, they must be done for it to function.

So the previous autofs behavior was problematic for find and couldn't be
fixed, but was OK for long directory listings. Pretty much a crap
situation.

There is also the common case where applications perform a stat(2) (or
any LOOKUP_FOLLOW type) call (other than when used in listing a
directory) where the automount should also be done and complains about
that behavior were met with an explanation of why it was so and a
wontfix response. So for the bulk of cases automounting should be done
for LOOKUP_FOLLOW type system calls and not for the ~LOOKUP_FOLLOW.
Which is also a "natural" usage because user space largely does this the
way automounting needs already.

Coming back to the bug that Miklos referred to.

This was a case where long listing a directory caused automount child
directories to be mounted. But for directory listings we want don't want
to automount it's child directories. We also want the details on
symlinks, and don't want to follow them. In the reported bug there were
a couple of lgetxattr(2) calls and suddenly a getxattr(2) call which was
inconsistent usage and was causing the unwanted mounts. Even upstream
conceded that this was inconsistent and accepted a path (well actually
two patches, one for the acl package and one for coreutils), and the
problem was gone.

In the time we have had this changed behavior we haven't had any further
reports of problems that I'm aware of. But there may be more to come, I
expect we will see some complains from GUI uses at some point too but
they will be a problem whether we mount on stat on not, since not
mounting the things they want to see is no good for them and mounting to
many things for them annoys them as well.

Now Trond has identified a number of examples that demonstrates why we
should not merge (or should revert) Miklos's patch, examples I couldn't
provide when he asked for them.

Again, I believe we got it right the first time, and we should work with
user space to provide any information and assistance needed for them to
change to accommodate the semantic difference which has been needed for
many years, and has (had) now been done.

So, sorry Miklos, but I now think your patch should be reverted.

Ian