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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, Sep 23, 2011 at 8:41 AM, Ian Kent <raven@themaw.net> wrote:
>
> My point is that, since we haven't had any non-trivial problems reported
> due to the semantic change, in what six months or more, why change it
> now?

We may indeed have to revert for sanity at this point, but I have to
say that I think the arguments have been very weak, and the logic for
when to auto-mount and when not to seems to not really be based on any
real logic.

For example, I think the whole "let's consider lstat different from
stat" model is broken. It works for symlinks, but that's because

 - applications *know* about the symlink difference

 - lstat actually *informs* about the symlink

neither of which is true for automounts. So quite frankly, I think
trying to conflate automount behavior with symlink behavior is a
completely bogus model to begin with, and has no actual redeeming
values except for an implementation issue (->follow_link) that no
longer even exists!

So I seriously think that the old autofs model is technically
superior. Which doesn't make it the only right one, of course. But I
really do think it's totally broken to think that lstat works
differently from stat.

So I would argue that using lstat as a differentiator for this is bad, because

 - it's not what we've done historically
 - it's a crazy hack introduced by implementation reasons, not logic
 - it's against all lstat documentation
 - it's inflexible and makes it hard to script

Now, introducing a new internal kernel flag is in many ways even
*worse*, because it's going to make it even more ad-hoc and
implementation issue, and even less visible and logical to actual
users who don't care.

So *that* is why I thought the LOOKUP_DIRECTORY flag was so nice. And
I still suspect that if paired with LOOKUP_OPEN, it would actually be
a complete solution that avoids the crazy issues with "random
implementation detail" and could give us something that is both
accessible from user space *and* something we can explain to a user
from a logical basis.

In other words, if we are going to accept changing semantics (and
apparently we have to), let's just make sure the ones we pick are the
*sensible* ones.

                Linus