All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Ian Kent <ikent@redhat.com>, Jeff Layton <jlayton@redhat.com>,
	Trond Myklebust <trondmy@primarydata.com>,
	"viro\@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mkoutny\@suse.com" <mkoutny@suse.com>,
	"linux-nfs\@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>
Subject: Re: Do we really need d_weak_revalidate???
Date: Thu, 24 Aug 2017 13:21:33 +1000	[thread overview]
Message-ID: <87lgm9k5vm.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <1bfd81b3-4f16-b0a7-6b51-0c0cb23ed0a0@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 6677 bytes --]

On Wed, Aug 23 2017, Ian Kent wrote:

> On 23/08/17 10:32, Ian Kent wrote:
>> On 23/08/17 09:06, NeilBrown wrote:
>>> On Mon, Aug 21 2017, Ian Kent wrote:
>>>
>>>>>
>>>>> A mount isn't triggered by kern_path(pathname, 0, &path).
>>>>> That '0' would need to include one of
>>>>>   LOOKUP_PARENT | LOOKUP_DIRECTORY |
>>>>>   LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT
>>>>>
>>>>> to trigger an automount (otherwise you just get -EISDIR).
>>>>
>>>> It's perfectly sensible to think that but there is a case where a
>>>> a mount is triggered when using kern_path().
>>>>
>>>> The EISDIR return occurs for positive dentrys, negative dentrys
>>>> will still trigger an automount (which is autofs specific,
>>>> indirect mount map using nobrowse option, the install default).
>>>
>>> Ok, I understand this better now.  This difference between direct and
>>> indirect mounts is slightly awkward. It is visible from user-space, but
>>> not elegant to document.
>>> When you use O_PATH to open a direct automount that has not already been
>>> triggered, the open returns the underlying directory (and fstatfs
>>> confirms that it is AUTOFS_SUPER_MAGIC).  When you use O_PATH on
>>> an indirect automount, it *will* trigger the automount when "nobrowse" is
>>> in effect, but it won't when "browse" is in effect.
>> 
>> 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.
>> 
>>>
>>> So we cannot just say "O_PATH doesn't trigger automounts", which is
>>> essentially what I said in
>>>
>>> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=97a45d02e6671482e8b2cdcce3951930bf6bdb94
>>>
>>> It might be possible to modify automount so that it was more consistent
>>> - i.e. if the point is triggered by a mkdir has been done, just to the
>>> mkdir.  If it is triggered after a mkdir has been done, do the mount.  I
>>> guess that might be racy, and in any case is hard to justify.
>>>
>>> Maybe I should change it to be about "direct automounts", and add a note
>>> that indirect automounts aren't so predictable.
>> 
>> Right and the semantics should be much more consistent in the near future.
>> I hope (and expect) this semantic change won't cause problems.
>> 
>>>
>>> But back to my original issue of wanting to discard
>>> kern_path_mountpoint, what would you think of the following approach -
>>> slight revised from before.
>>>
>>> Thanks,
>>> NeilBrown
>>>
>>> diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
>>> index beef981aa54f..7663ea82e68d 100644
>>> --- a/fs/autofs4/autofs_i.h
>>> +++ b/fs/autofs4/autofs_i.h
>>> @@ -135,10 +135,13 @@ static inline struct autofs_info *autofs4_dentry_ino(struct dentry *dentry)
>>>  /* autofs4_oz_mode(): do we see the man behind the curtain?  (The
>>>   * processes which do manipulations for us in user space sees the raw
>>>   * filesystem without "magic".)
>>> + * A process performing certain ioctls can get temporary oz status.
>>>   */
>>> +extern struct task_struct *autofs_tmp_oz;
>>>  static inline int autofs4_oz_mode(struct autofs_sb_info *sbi)
>>>  {
>>> -	return sbi->catatonic || task_pgrp(current) == sbi->oz_pgrp;
>>> +	return sbi->catatonic || task_pgrp(current) == sbi->oz_pgrp ||
>>> +		autofs_tmp_oz == current;
>>>  }
>>>  
>>>  struct inode *autofs4_get_inode(struct super_block *, umode_t);
>>> diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
>>> index dd9f1bebb5a3..d76401669a20 100644
>>> --- a/fs/autofs4/dev-ioctl.c
>>> +++ b/fs/autofs4/dev-ioctl.c
>>> @@ -200,6 +200,20 @@ static int autofs_dev_ioctl_protosubver(struct file *fp,
>>>  	return 0;
>>>  }
>>>  
>>> +struct task_struct *autofs_tmp_oz;
>>> +int kern_path_oz(const char *pathname, int flags, struct path *path)
>>> +{
>>> +	static DEFINE_MUTEX(autofs_oz);
>>> +	int err;
>>> +
>>> +	mutex_lock(&autofs_oz);
>>> +	autofs_tmp_oz = current;
>>> +	err = kern_path(pathname, flags, path);
>>> +	autofs_tmp_oz = NULL;
>>> +	mutex_unlock(&autofs_oz);
>>> +	return err;
>>> +}
>>> +
>> 
>> It's simple enough but does look like it will attract criticism as being
>> a hack!
>> 
>> The kern_path_locked() function is very similar to what was originally
>> done, along with code to look down the mount stack (rather than up the
>> way it does now) to get the mount point. In this case, to be valid the
>> dentry can't be a symlink so that fits kern_path_locked() too.
>
> Oh wait, that __lookup_hash() tries too hard to resolve the dentry,
> that won't quite work, and maybe d_lookup() can't be used safely in
> this context either ....
>

Why do you think that __look_hash() tries too hard?
It does call into the filesystem ->lookup() if the name isn't in the
cache, which probably isn't strictly needed, but that isn't harmful and
the current code does that.

Some the following seems sensible to me (though I haven't tested it).

Thanks,
NeilBrown


diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
index dd9f1bebb5a3..859c198d0163 100644
--- a/fs/autofs4/dev-ioctl.c
+++ b/fs/autofs4/dev-ioctl.c
@@ -208,12 +208,16 @@ static int find_autofs_mount(const char *pathname,
 {
 	struct path path;
 	int err;
+	struct dentry *de, *parent;
+
+	de = kern_path_locked(pathname, &path);
+	if (IS_ERR(de))
+		return PTR_ERR(de);
+	parent = path.dentry;
+	path.dentry = de;
 
-	err = kern_path_mountpoint(AT_FDCWD, pathname, &path, 0);
-	if (err)
-		return err;
 	err = -ENOENT;
-	while (path.dentry == path.mnt->mnt_root) {
+	do {
 		if (path.dentry->d_sb->s_magic == AUTOFS_SUPER_MAGIC) {
 			if (test(&path, data)) {
 				path_get(&path);
@@ -222,10 +226,11 @@ static int find_autofs_mount(const char *pathname,
 				break;
 			}
 		}
-		if (!follow_up(&path))
-			break;
-	}
+	} while (follow_down_one(&path));
+
 	path_put(&path);
+	inode_unlock(d_inode(parent));
+	dput(parent);
 	return err;
 }
 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2017-08-24  3:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11  4:31 Do we really need d_weak_revalidate??? NeilBrown
2017-08-11  5:55 ` Trond Myklebust
2017-08-11  5:55   ` Trond Myklebust
2017-08-11 11:01   ` Jeff Layton
2017-08-13 23:36     ` NeilBrown
2017-08-14 10:10       ` Jeff Layton
2017-08-16  2:43         ` NeilBrown
2017-08-16 11:34           ` Jeff Layton
2017-08-16 23:47             ` NeilBrown
2017-08-17  2:20             ` Ian Kent
2017-08-18  5:24               ` NeilBrown
2017-08-18  6:47                 ` Ian Kent
2017-08-18  6:55                   ` Ian Kent
2017-08-21  6:23                   ` NeilBrown
2017-08-21  6:32                     ` Ian Kent
2017-08-21  7:46                       ` NeilBrown
2017-08-23  1:06                       ` NeilBrown
2017-08-23  2:32                         ` Ian Kent
2017-08-23  2:40                           ` Ian Kent
2017-08-23  2:54                             ` Ian Kent
2017-08-23  7:51                               ` Ian Kent
2017-08-24  3:21                             ` NeilBrown [this message]
2017-08-24  4:35                               ` Ian Kent
2017-08-24  4:07                           ` NeilBrown
2017-08-24  4:47                             ` Ian Kent
2017-08-24  4:58                             ` Ian Kent
2017-08-24 11:03                             ` Michael Kerrisk (man-pages)
2017-08-25  0:05                               ` Ian Kent
2017-08-25  5:32                               ` [PATCH manpages] stat.2: correct AT_NO_AUTOMOUNT text and general revisions NeilBrown
2017-09-14 13:38                                 ` Michael Kerrisk (man-pages)
2017-09-14 22:25                                   ` NeilBrown
2017-09-16 13:11                                     ` Michael Kerrisk (man-pages)
2017-09-08 15:15                             ` Do we really need d_weak_revalidate??? David Howells
2017-08-13 23:29   ` NeilBrown
2017-08-24  6:34     ` NeilBrown

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=87lgm9k5vm.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=dhowells@redhat.com \
    --cc=ikent@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mkoutny@suse.com \
    --cc=trondmy@primarydata.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.