From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Linux Filesystem Development <linux-fsdevel@vger.kernel.org>
Subject: [PATCH] Allow kernel-only mount interfaces...
Date: Thu, 10 Feb 2005 13:41:23 -0500 [thread overview]
Message-ID: <1108060883.9757.33.camel@lade.trondhjem.org> (raw)
Hi,
I'm working on straightening out a problem we have with NFSv4 in the
case where the server exports a tree of filesystems (as we also do in
NFSv2/v3 with the "nohide" option).
If the client mounts such a tree, it is supposed to detect whenever it
crosses a mountpoint on the server, and basically automount the new
filesystem in-place. The main reason for wanting to do so is that NFSv4
allows for individual filesystems to be migrated and/or replicated to
other servers.
In order to respect atomicity guarantees, it would be nice to do this
automounting in-kernel within nfs_lookup(). For efficiency reasons, it
would be nice to be able to pass the old superblock as a parameter to
the mount code. The problem is that the current mount interfaces do not
allow the kernel to have a private api that differs from the standard
userland mount.
Would something like the appended patch be an acceptable method of
implementing such a private mount api?
Cheers,
Trond
VFS: Add GPL_EXPORTED function vfs_kern_mount()
do_kern_mount() does not allow the kernel to use private mount interfaces
without exposing the same interfaces to userland. The problem is that the
filesystem is referenced by name, thus meaning that it and its mount
interface must be registered in the global filesystem list.
vfs_kern_mount() passes the struct file_system_type as an explicit
parameter in order to overcome this limitation.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
super.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
Index: linux-2.6.11-rc3/fs/super.c
===================================================================
--- linux-2.6.11-rc3.orig/fs/super.c
+++ linux-2.6.11-rc3/fs/super.c
@@ -794,9 +794,8 @@ struct super_block *get_sb_single(struct
EXPORT_SYMBOL(get_sb_single);
struct vfsmount *
-do_kern_mount(const char *fstype, int flags, const char *name, void *data)
+vfs_kern_mount(struct file_system_type *type, int flags, const char *name, void *data)
{
- struct file_system_type *type = get_fs_type(fstype);
struct super_block *sb = ERR_PTR(-ENOMEM);
struct vfsmount *mnt;
int error;
@@ -835,7 +834,6 @@ do_kern_mount(const char *fstype, int fl
mnt->mnt_parent = mnt;
mnt->mnt_namespace = current->namespace;
up_write(&sb->s_umount);
- put_filesystem(type);
return mnt;
out_sb:
up_write(&sb->s_umount);
@@ -846,10 +844,20 @@ out_free_secdata:
out_mnt:
free_vfsmnt(mnt);
out:
- put_filesystem(type);
return (struct vfsmount *)sb;
}
+EXPORT_SYMBOL_GPL(vfs_kern_mount);
+
+struct vfsmount *
+do_kern_mount(const char *fstype, int flags, const char *name, void *data)
+{
+ struct file_system_type *type = get_fs_type(fstype);
+ struct vfsmount *mnt = vfs_kern_mount(type, flags, name, data);
+ put_filesystem(type);
+ return mnt;
+}
+
EXPORT_SYMBOL_GPL(do_kern_mount);
struct vfsmount *kern_mount(struct file_system_type *type)
--
Trond Myklebust <trond.myklebust@fys.uio.no>
next reply other threads:[~2005-02-10 18:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-10 18:41 Trond Myklebust [this message]
2005-02-10 19:01 ` [PATCH] Allow kernel-only mount interfaces Andreas Dilger
2005-02-10 19:14 ` Trond Myklebust
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=1108060883.9757.33.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=linux-fsdevel@vger.kernel.org \
/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).