From: NeilBrown <neilb@suse.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 01/20] Documentation: remove outdated information from automount-support.txt
Date: Mon, 23 Mar 2015 13:37:38 +1100 [thread overview]
Message-ID: <20150323023738.8161.41308.stgit@notabene.brown> (raw)
In-Reply-To: <20150323023258.8161.32467.stgit@notabene.brown>
The guidelines for adding automount support to a filesystem
in filesystems/automount-support.txt is out or date.
filesystems/autofs4.txt contains more current text, so replace
the out-of-date content with a reference to that.
Signed-off-by: NeilBrown <neilb@suse.de>
---
Documentation/filesystems/automount-support.txt | 51 ++++++-----------------
1 file changed, 13 insertions(+), 38 deletions(-)
diff --git a/Documentation/filesystems/automount-support.txt b/Documentation/filesystems/automount-support.txt
index 7cac200e2a85..7eb762eb3136 100644
--- a/Documentation/filesystems/automount-support.txt
+++ b/Documentation/filesystems/automount-support.txt
@@ -1,41 +1,15 @@
-Support is available for filesystems that wish to do automounting support (such
-as kAFS which can be found in fs/afs/). This facility includes allowing
-in-kernel mounts to be performed and mountpoint degradation to be
-requested. The latter can also be requested by userspace.
+Support is available for filesystems that wish to do automounting
+support (such as kAFS which can be found in fs/afs/ and NFS in
+fs/nfs/). This facility includes allowing in-kernel mounts to be
+performed and mountpoint degradation to be requested. The latter can
+also be requested by userspace.
======================
IN-KERNEL AUTOMOUNTING
======================
-A filesystem can now mount another filesystem on one of its directories by the
-following procedure:
-
- (1) Give the directory a follow_link() operation.
-
- When the directory is accessed, the follow_link op will be called, and
- it will be provided with the location of the mountpoint in the nameidata
- structure (vfsmount and dentry).
-
- (2) Have the follow_link() op do the following steps:
-
- (a) Call vfs_kern_mount() to call the appropriate filesystem to set up a
- superblock and gain a vfsmount structure representing it.
-
- (b) Copy the nameidata provided as an argument and substitute the dentry
- argument into it the copy.
-
- (c) Call do_add_mount() to install the new vfsmount into the namespace's
- mountpoint tree, thus making it accessible to userspace. Use the
- nameidata set up in (b) as the destination.
-
- If the mountpoint will be automatically expired, then do_add_mount()
- should also be given the location of an expiration list (see further
- down).
-
- (d) Release the path in the nameidata argument and substitute in the new
- vfsmount and its root dentry. The ref counts on these will need
- incrementing.
+See section "Mount Traps" of Documentation/filesystems/autofs4.txt
Then from userspace, you can just do something like:
@@ -61,17 +35,18 @@ AUTOMATIC MOUNTPOINT EXPIRY
===========================
Automatic expiration of mountpoints is easy, provided you've mounted the
-mountpoint to be expired in the automounting procedure outlined above.
+mountpoint to be expired in the automounting procedure outlined separately.
To do expiration, you need to follow these steps:
- (3) Create at least one list off which the vfsmounts to be expired can be
- hung. Access to this list will be governed by the vfsmount_lock.
+ (1) Create at least one list off which the vfsmounts to be expired can be
+ hung.
- (4) In step (2c) above, the call to do_add_mount() should be provided with a
- pointer to this list. It will hang the vfsmount off of it if it succeeds.
+ (2) When a new mountpoint is created in the ->d_automount method, add
+ the mnt to the list using mnt_set_expiry()
+ mnt_set_expiry(newmnt, &afs_vfsmounts);
- (5) When you want mountpoints to be expired, call mark_mounts_for_expiry()
+ (3) When you want mountpoints to be expired, call mark_mounts_for_expiry()
with a pointer to this list. This will process the list, marking every
vfsmount thereon for potential expiry on the next call.
next prev parent reply other threads:[~2015-03-23 2:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 2:37 [PATCH 00/20] Support follow_link in RCU-walk - V3 NeilBrown
2015-03-23 2:37 ` [PATCH 02/20] STAGING/lustre: limit follow_link recursion using stack space NeilBrown
2015-04-18 3:01 ` Al Viro
2015-04-19 20:57 ` Andreas Dilger
2015-04-19 21:33 ` Al Viro
2015-04-20 2:29 ` Al Viro
2015-03-23 2:37 ` [PATCH 03/20] VFS: replace {, total_}link_count in task_struct with pointer to nameidata NeilBrown
2015-03-23 2:37 ` NeilBrown [this message]
2015-03-23 2:37 ` [PATCH 10/20] security: make inode_follow_link RCU-walk aware NeilBrown
2015-03-23 2:37 ` [PATCH 04/20] ovl: rearrange ovl_follow_link to it doesn't need to call ->put_link NeilBrown
2015-03-23 2:37 ` [PATCH 07/20] VFS: remove nameidata args from ->follow_link NeilBrown
2015-03-23 2:37 ` [PATCH 06/20] SECURITY: remove nameidata arg from inode_follow_link NeilBrown
2015-03-23 2:37 ` [PATCH 05/20] VFS: replace nameidata arg to ->put_link with a char* NeilBrown
2015-03-23 2:37 ` [PATCH 09/20] security/selinux: pass 'flags' arg to avc_audit() and avc_has_perm_flags() NeilBrown
2015-03-23 2:37 ` [PATCH 11/20] VFS/namei: use terminate_walk when symlink lookup fails NeilBrown
2015-03-23 2:37 ` [PATCH 08/20] VFS: make all ->follow_link handlers aware for LOOKUP_RCU NeilBrown
2015-03-23 2:37 ` [PATCH 13/20] VFS/namei: abort RCU-walk on symlink if atime needs updating NeilBrown
2015-03-23 2:37 ` [PATCH 14/20] VFS/namei: add 'inode' arg to put_link() NeilBrown
2015-04-17 16:25 ` Al Viro
2015-04-17 19:09 ` Al Viro
2015-04-18 8:09 ` Al Viro
2015-03-23 2:37 ` [PATCH 16/20] VFS/namei: enable RCU-walk when following symlinks NeilBrown
2015-03-23 2:37 ` [PATCH 19/20] XFS: allow follow_link to often succeed in RCU-walk NeilBrown
2015-03-23 2:37 ` [PATCH 20/20] NFS: support LOOKUP_RCU in nfs_follow_link NeilBrown
2015-03-23 2:37 ` [PATCH 18/20] xfs: use RCU to free 'struct xfs_mount' NeilBrown
2015-03-23 2:37 ` [PATCH 17/20] VFS/namei: handle LOOKUP_RCU in page_follow_link_light NeilBrown
2015-03-23 2:37 ` [PATCH 12/20] VFS/namei: new flag to support RCU symlinks: LOOKUP_LINK_RCU NeilBrown
2015-03-23 2:37 ` [PATCH 15/20] VFS/namei: enhance follow_link to support RCU-walk NeilBrown
2015-03-25 23:23 ` [PATCH 00/20] Support follow_link in RCU-walk - V3 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=20150323023738.8161.41308.stgit@notabene.brown \
--to=neilb@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).