Re: [PATCH] NFS4: Revert commit to make the automount code ignore LOOKUP_FOLLOW

[David Howells <dhowells@redhat.com>]

One thing that does concern me a little about bringing back the old behaviour
for stat and *xattr is that there is no reliable way to get at the directory
mounted directly on the mountpoint (ie. mnt_root).

The problem is that:

 (a) you have to know to trigger the automount with some other operation first
     and

 (b) the other operation is not atomic wrt to the following stat/xattr, and so
     the thing mounted on the automount point may be subject to expiration and
     auto-unmounting before the second operation can proceed.

I'm not sure how much of a problem these are in practice.  Certainly, I'd rate
(b) as being less serious than (a) as the expiration timeouts are generally
quite large.  (b) can be suppressed with chdir() or open() also - then you are
forcing retension of the vfsmount.

The problem can be ameliorated for such as fstatat() by passing an AT_ flag to
either suppress automounting or to force automounting, but there aren't any
xattr calls, for example, that take this.


I guess it comes down to defining two things:

 (1) What behaviour do we actually want?

 (2) What departure from previous behaviour are we willing to put up with?


On the first, I would say definitely we want mass-stat'ers (such as ls) to not
cause mass automounting.  But for ls, that has been achieved in userspace;
there are, however, other programs to consider.

I would also say that we do not want lstat(), l*xattr() and co. to cause
automounting - but maybe they should.  Perhaps if you don't want to cause
automounting, you should explicitly pass AT_NO_AUTOMOUNT, and all path-taking
VFS calls should have variants that accept this flag.

Do we want to have guaranteed access to the root of an automounted fs?  Are we
willing to add getxattrat and similar to get it?

David