From: David Howells <dhowells@redhat.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: dhowells@redhat.com, raven@themaw.net, npiggin@kernel.dk,
autofs@linux.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 00/18] Introduce automount support in the VFS [ver #4]
Date: Fri, 14 Jan 2011 11:43:48 +0000 [thread overview]
Message-ID: <2443.1295005428@redhat.com> (raw)
In-Reply-To: <20110114070224.GB19804@ZenIV.linux.org.uk>
Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > d_op->d_automount() may return one of:
> >
> > (a) The vfsmount mounted upon that dentry, in which case pathwalk will
> > move to the root dentry of that vfsmount. ->d_automount() must
> > have in some manner mounted this before returning.
> >
> > (b) NULL if something was already mounted there, in which case
> > pathwalk will loop around and recheck the mountings.
>
> That makes very little sense as-is. Look:
> * autofs4 never does (a)
> * everybody else could replace (a) with (b) just fine - we do (a)
> only when we'd just mounted new vfsmount on top of path. So (b) would lead
> to follow_managed() looping over, finding DCACHE_MOUNTED and cheerfully
> transiting into the root of that vfsmount.
Indeed. It's merely an optimisation and not strictly necessary. I suppose
that, given the amount of time that's probably spent in performing the mount
part of the automount, repeating the check is negligible cost.
> Now, I'd like to have (a) and (b) distinct, but not in that fashion. Namely,
> let's take do_add_mount() et.al. into follow_automount().
I presume that people aren't expected to do things like do_move_mount() here,
but might they want to do a bind mount? Or do we just say if they want to do
something more exotic than do_add_mount(), they have to follow path (b)?
> Leave autofs4 as in your series; it'll be completely unaffected. But switch
> all (b) in nfs/cifs/afs over to modified (a). That is,
> * have vfsmount created as it's done in your series
> * grab extra reference and put it on chosen list. That'd be done
> by helper in fs/namespace.c under namespace_sem. Extra ref would make sure
> that nobody walking the list would decide that it's expirable.
It would be simpler, perhaps, to allow d_automount() to return the list also:
struct vfsmount *(*d_automount)(struct path *mountpoint,
struct list_head **expiry_list_to_use);
This pointer can then be passed directly to do_add_mount() and we don't have
to worry about having an extra reference or cleaning up the list on error.
> * schedule whatever expiry activity we currently do.
> * return vfsmount
> In follow_automount() we'd see that we have non-NULL and non-ERR_PTR. Then
> we'd attempt do_add_mount(), without bothering to pass it expiry list. And
> do the same checks for return value, etc. we currently do in the method
> instances; just remember that we have an extra vfsmount reference that will
> need to be dropped and that we'll need to take the sucker off the expiry list
> in case we decide we don't need it (again, namespace.c helper).
>
> As the result, we stop abusing do_add_mount() in there. Moreover, with
> pending mnt_devname nfs rework we will be able to get rid of passing
> vfsmount to ->d_automount(), AFAICT, which would be nice...
:-)
David
next prev parent reply other threads:[~2011-01-14 11:44 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 21:53 [PATCH 00/18] Introduce automount support in the VFS [ver #4] David Howells
2011-01-13 21:54 ` [PATCH 01/18] Add a dentry op to handle automounting rather than abusing follow_link() " David Howells
2011-01-16 0:09 ` Al Viro
2011-01-16 1:17 ` Al Viro
2011-01-16 18:12 ` David Howells
2011-01-13 21:54 ` [PATCH 02/18] Add a dentry op to allow processes to be held during pathwalk transit " David Howells
2011-01-13 21:54 ` [PATCH 03/18] From: David Howells <dhowells@redhat.com> " David Howells
2011-01-13 21:54 ` [PATCH 04/18] AFS: Use d_automount() rather than abusing follow_link() " David Howells
2011-01-13 21:54 ` [PATCH 05/18] NFS: " David Howells
2011-01-13 21:54 ` [PATCH 06/18] CIFS: " David Howells
2011-01-13 21:54 ` [PATCH 07/18] Remove the automount through follow_link() kludge code from pathwalk " David Howells
2011-01-13 21:54 ` [PATCH 08/18] autofs4: Add d_automount() dentry operation " David Howells
2011-01-13 21:54 ` [PATCH 09/18] autofs4: Add d_manage() " David Howells
2011-01-14 13:51 ` Ian Kent
2011-01-14 14:37 ` Nick Piggin
2011-01-14 15:47 ` Nick Piggin
2011-01-14 15:35 ` David Howells
2011-01-14 15:46 ` Nick Piggin
2011-01-13 21:54 ` [PATCH 10/18] autofs4: Remove unused code " David Howells
2011-01-13 21:54 ` [PATCH 11/18] autofs4: Clean up inode operations " David Howells
2011-01-13 21:55 ` [PATCH 12/18] autofs4: Clean up dentry " David Howells
2011-01-13 21:55 ` [PATCH 13/18] autofs4: Clean up autofs4_free_ino() " David Howells
2011-01-14 16:03 ` Al Viro
2011-01-13 21:55 ` [PATCH 14/18] autofs4: Fix wait validation " David Howells
2011-01-13 21:55 ` [PATCH 15/18] autofs4: Add v4 pseudo direct mount support " David Howells
2011-01-13 21:55 ` [PATCH 16/18] autofs4: Bump version " David Howells
2011-01-13 21:55 ` [PATCH 17/18] Remove a further kludge from __do_follow_link() " David Howells
2011-01-13 21:55 ` [PATCH 18/18] Allow d_manage() to be used in RCU-walk mode " David Howells
2011-01-14 7:02 ` [PATCH 00/18] Introduce automount support in the VFS " Al Viro
2011-01-14 7:05 ` Al Viro
2011-01-14 11:20 ` David Howells
2011-01-14 11:43 ` David Howells [this message]
2011-01-14 15:46 ` Al Viro
2011-01-14 17:26 ` [PATCH 19/18] Unexport do_add_mount() and add in follow_automount(), not ->d_automount() David Howells
2011-01-14 17:43 ` Al Viro
2011-01-14 17:56 ` Al Viro
2011-01-14 18:06 ` Al Viro
2011-01-14 22:07 ` Nick Piggin
2011-01-15 13:30 ` Al Viro
2011-01-15 18:33 ` Nick Piggin
2011-01-16 0:24 ` Al Viro
2011-01-16 1:21 ` Nick Piggin
2011-01-15 18:46 ` Nick Piggin
2011-01-14 17:30 ` David Howells
2011-01-14 11:54 ` [PATCH 00/18] Introduce automount support in the VFS [ver #4] David Howells
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=2443.1295005428@redhat.com \
--to=dhowells@redhat.com \
--cc=autofs@linux.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=npiggin@kernel.dk \
--cc=raven@themaw.net \
--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;
as well as URLs for NNTP newsgroup(s).