Re: Do we really need d_weak_revalidate???

[Michael Kerrisk (man-pages)]

Hi Neil,

On 24 August 2017 at 06:07, NeilBrown <neilb@xxxxxxxx> wrote:
> On Wed, Aug 23 2017, Ian Kent wrote:
>
>>
>> That inconsistency has bothered me for quite a while now.
>>
>> It was carried over from the autofs module behavior when automounting
>> support was added to the VFS. What's worse is it prevents the use of
>> the AT_NO_AUTOMOUNT flag from working properly with fstatat(2) and with
>> statx().
>>
>> There is some risk in changing that so it does work but it really does
>> need to work to enable userspace to not trigger an automount by using
>> this flag.
>>
>> So that's (hopefully) going to change soonish, see:
>> http://ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-at_no_automount-not-being-honored.patch
>>
>> The result should be that stat family calls don't trigger automounts except
>> for fstatat(2) and statx() which will require the AT_NO_AUTOMOUNT flag.
>>
>
> oooh, yes.  That's much better - thanks.
>
> We should make sure that change gets into the man pages...
>
> First however, we should probably correct the man page!
> stat.2 says:
>
>
>   NOTES
>        On Linux, lstat() will generally not trigger  automounter
>        action,  whereas  stat()  will  (but  see  the description of
>        fstatat() AT_NO_AUTOMOUNT fag, above).
>
> which is wrong: lstat and stat treat automounts the same.
> @Michael: do you recall why you inserted that text?  The commit message
> in commit 1ef5b2805471 ("stat.2: Cosmetic reworking of timestamp
> discussion in NOTES") is not very helpful.

That commit really was just cosmetic changes. The change that
introduced the text was 82d2be3d9d66b7, based on a note from Peter
Anvin:

[[
    > > Additionally, you may want to make a note in the stat/lstat man page tha
t on
    > > Linux, lstat(2) will generally not trigger automounter action, whereas
    > > stat(2) will.
    >
    > I don't understand this last piece.  Can you say some more.  (I'm not
    > familiar with automounter details.)

    An automounter (either an explicit one, like autofs, or an implicit
    one, such as are used by AFS or NFSv4) is something that triggers
    a mount when something is touched.

    However, it's undesirable to automount, say, everyone's home
    directory just because someone opened up /home in their GUI
    browser or typed "ls -l /home".  The early automounters simply
    didn't list the contents until you accessed it by name;
    this is still the case when you can't enumerate a mapping
    (say, all DNS names under /net).  However, this is extremely
    inconvenient, too.

    The solution we ended up settling on is to create something
    that looks like a directory (i.e. reports S_IFDIR in stat()),
    but behaves somewhat like a symlink.  In particular, when it is
    accessed in a way where a symlink would be dereferenced,
    the automount triggers and the directory is mounted.  However,
    system calls which do *not* cause a symlink to be dereferenced,
    like lstat(), also do not cause the automounter to trigger.
    This means that "ls -l", or a GUI file browser, can see a list
    of directories without causing each one of them to be automounted.

            -hpa
]]

Cheers,

Michael

> I propose correcting to
>
>   NOTES:
>       On Linux, lstat() nor stat() act as though AT_NO_AUTOMOUNT was set
>       and will not trigger automounter action for direct automount
>       points, though they may (prior to 4.14) for indirect automount
>       points.
>
>
> The more precise details, that automount action for indirect automount
> points is not triggered when the 'browse' option is used, is probably
> not necessary.
>
> Ian: if you agree with that text, and Michael doesn't provide alternate
> evidence, I'll submit a formal patch for the man page.... or should we
> just wait until the patch actually lands?
>
> Thanks,
> NeilBrown
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/