From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ian Kent <raven@themaw.net>
Cc: Valerie Aurora <vaurora@redhat.com>,
linux-fsdevel@vger.kernel.org, Jan Blunck <jblunck@suse.de>,
autofs@linux.kernel.org, sfrench@samba.org,
Trond.Myklebust@netapp.com, David Howells <dhowells@redhat.com>
Subject: Re: [PATCH 1/7] autofs4: Save autofs trigger's vfsmount in super block info
Date: Mon, 18 Jan 2010 05:59:29 +0000 [thread overview]
Message-ID: <20100118055929.GS19799@ZenIV.linux.org.uk> (raw)
In-Reply-To: <4B53E1B5.2080202@themaw.net>
On Mon, Jan 18, 2010 at 12:21:09PM +0800, Ian Kent wrote:
> In that case we may find an autofs mount that has something mounted on
> top of it and user space wants to know the super of the covering mount.
>
> If there is something mounted on top of it user space needs to know if
> it is another autofs file system or some other type of file system. So
> if the nameidata path, located by autofs_dev_ioctl_find_super(), is not
> the top (or bottom, depending on the terminology you prefer) then we
> need to follow the mount and return the magic of the thing mounted on
> top of it.
IDGI. What you are doing there is
if (path.mnt->mnt_mountpoint != path.mnt->mnt_root) {
if (follow_down(&path))
magic = path.mnt->mnt_sb->s_magic;
}
and I don't think it means what you think it means. Just what is that
mnt_mountpoint check about? Before that point we'd found the autofs
vfsmount M that
1) M is mounted on <name>
2) M->mnt_sb has the right s_dev
3) M is the closest one to root in mount tree out of vfsmounts
satisfying (1) and (2)
Now we check that
4) the mountpoint M is attached to has dentry different from
M->mnt_root. That's an interesting thing to check, seeing that the
only way to get it false is to have mount --bind name name, with name
not being the mountpoint before that. And M being the result of
that mount --bind.
5) something is mounted on top of root of M.
Then we proceed to return the s_magic of that something. For one thing,
if there *are* several vfsmounts satisfying (1,2), which one do we really
want? For another, what's the intent of (4)? It looks very odd; what's
really being checked there?
In another branch we have
if (path.dentry->d_inode &&
path.mnt->mnt_root == path.dentry) {
err = 1;
magic = path.dentry->d_inode->i_sb->s_magic;
}
and AFAICT, path.dentry->d_inode == NULL is impossible there. Besides,
path.mnt->mnt_sb->s_magic would be simpler anyway (and evaluate to
the same thing).
next prev parent reply other threads:[~2010-01-18 5:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-23 23:36 [PATCH 0/7] VFS prep for union mounts/writable overlays Valerie Aurora
2009-12-23 23:36 ` [PATCH 1/7] autofs4: Save autofs trigger's vfsmount in super block info Valerie Aurora
2009-12-23 23:36 ` [PATCH 2/7] VFS: Make lookup_hash() return a struct path Valerie Aurora
2009-12-23 23:36 ` [PATCH 3/7] VFS: Make real_lookup() " Valerie Aurora
2009-12-23 23:37 ` [PATCH 4/7] VFS: Propagate mnt_flags into do_loopback Valerie Aurora
2009-12-23 23:37 ` [PATCH 5/7] VFS: Add read-only users count to superblock Valerie Aurora
2009-12-23 23:37 ` [PATCH 6/7] VFS: BUG_ON() rehash of an already hashed dentry Valerie Aurora
2009-12-23 23:37 ` [PATCH 7/7] VFS: Remove unnecessary micro-optimization in cached_lookup() Valerie Aurora
2010-01-02 0:44 ` [PATCH 1/7] autofs4: Save autofs trigger's vfsmount in super block info Ian Kent
2010-01-14 5:43 ` Al Viro
2010-01-14 19:18 ` Valerie Aurora
2010-01-15 6:05 ` Ian Kent
2010-01-15 8:03 ` Al Viro
2010-01-15 14:55 ` David Howells
2010-01-15 16:58 ` Al Viro
2010-01-15 17:08 ` David Howells
2010-01-15 17:26 ` Al Viro
2010-01-16 10:17 ` Al Viro
2010-01-17 17:57 ` Al Viro
2010-01-18 4:21 ` Ian Kent
2010-01-18 5:59 ` Al Viro [this message]
2010-01-18 9:14 ` Ian Kent
2010-01-18 10:27 ` Al Viro
2010-01-18 19:35 ` Trond Myklebust
2010-01-25 8:16 ` H. Peter Anvin
2010-01-19 7:05 ` Ian Kent
2010-01-15 17:36 ` Steve French
2010-01-18 5:08 ` Ian Kent
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=20100118055929.GS19799@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=Trond.Myklebust@netapp.com \
--cc=autofs@linux.kernel.org \
--cc=dhowells@redhat.com \
--cc=jblunck@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=raven@themaw.net \
--cc=sfrench@samba.org \
--cc=vaurora@redhat.com \
/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.