public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	miklos@szeredi.hu, raven@themaw.net, viro@zeniv.linux.org.uk,
	gregkh@suse.de, linux-nfs@vger.kernel.org,
	leonardo.lists@gmail.com
Subject: Re: [PATCH] NFS4: Revert commit to make the automount code ignore LOOKUP_FOLLOW
Date: Thu, 22 Sep 2011 11:33:06 -0400	[thread overview]
Message-ID: <20110922113306.1a831043@barsoom.rdu.redhat.com> (raw)
In-Reply-To: <6490.1316704925@redhat.com>

On Thu, 22 Sep 2011 16:22:05 +0100
David Howells <dhowells@redhat.com> wrote:

> 
> 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?
> 

I guess we recognize that we ought to allow userspace to have some
control over whether these syscalls will trigger an automount. So the
real question is -- what should the default be? Probably, we ought to
err on the side of caution and keep the default behavior the way it was
before 2.6.38.

-- 
Jeff Layton <jlayton@redhat.com>

  parent reply	other threads:[~2011-09-22 15:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-22 12:46 [PATCH] NFS4: Revert commit to make the automount code ignore LOOKUP_FOLLOW David Howells
2011-09-22 12:50 ` David Howells
2011-09-22 12:58 ` Miklos Szeredi
2011-09-22 13:41   ` David Howells
2011-09-22 14:23     ` Miklos Szeredi
2011-09-22 14:33 ` Linus Torvalds
2011-09-22 15:22   ` David Howells
2011-09-22 15:32     ` Miklos Szeredi
2011-09-22 15:33     ` Jeff Layton [this message]
2011-09-22 15:54     ` Ian Kent
2011-09-22 15:26   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110922113306.1a831043@barsoom.rdu.redhat.com \
    --to=jlayton@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=gregkh@suse.de \
    --cc=leonardo.lists@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=raven@themaw.net \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox