Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1717937

Re: Do we really need d_weak_revalidate???

From NeilBrown <neilb@suse.com>
Newsgroups linux.kernel
Subject Re: Do we really need d_weak_revalidate???
Date 2017-08-23 03:10 +0200
Message-ID <uhslb-27L-3@gated-at.bofh.it> (permalink)
References (7 earlier) <ufiJk-6RK-11@gated-at.bofh.it> <ufI15-7kE-25@gated-at.bofh.it> <ufJgt-85f-1@gated-at.bofh.it> <ugOnL-Gt-7@gated-at.bofh.it> <ugOxr-Jy-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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.

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.

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;
+}
+
 /* Find the topmost mount satisfying test() */
 static int find_autofs_mount(const char *pathname,
 			     struct path *res,
@@ -209,7 +223,8 @@ static int find_autofs_mount(const char *pathname,
 	struct path path;
 	int err;
 
-	err = kern_path_mountpoint(AT_FDCWD, pathname, &path, 0);
+	err = kern_path_oz(pathname, 0, &path);
+
 	if (err)
 		return err;
 	err = -ENOENT;
@@ -552,8 +567,7 @@ static int autofs_dev_ioctl_ismountpoint(struct file *fp,
 
 	if (!fp || param->ioctlfd == -1) {
 		if (autofs_type_any(type))
-			err = kern_path_mountpoint(AT_FDCWD,
-						   name, &path, LOOKUP_FOLLOW);
+			err = kern_path_oz(name, LOOKUP_FOLLOW, &path);
 		else
 			err = find_autofs_mount(name, &path,
 						test_by_type, &type);

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-14 01:40 +0200
  Re: Do we really need d_weak_revalidate??? Jeff Layton <jlayton@redhat.com> - 2017-08-14 12:20 +0200
    Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-16 04:50 +0200
      Re: Do we really need d_weak_revalidate??? Jeff Layton <jlayton@redhat.com> - 2017-08-16 13:40 +0200
        Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-17 01:50 +0200
        Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-17 04:30 +0200
          Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-18 07:30 +0200
            Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-18 08:50 +0200
              Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-18 09:00 +0200
              Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-21 08:30 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-21 08:40 +0200
                Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-21 09:50 +0200
                Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-23 03:10 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-23 04:40 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-23 04:50 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-23 05:00 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-23 10:00 +0200
                Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-24 05:30 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-24 06:40 +0200
                Re: Do we really need d_weak_revalidate??? NeilBrown <neilb@suse.com> - 2017-08-24 06:10 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-24 06:50 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-24 07:00 +0200
                Re: Do we really need d_weak_revalidate??? "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2017-08-24 13:10 +0200
                Re: Do we really need d_weak_revalidate??? Ian Kent <ikent@redhat.com> - 2017-08-25 02:10 +0200
                [PATCH manpages] stat.2: correct AT_NO_AUTOMOUNT text and general revisions. NeilBrown <neilb@suse.com> - 2017-08-25 07:40 +0200

csiph-web