linux-kernel - Re: [PATCH 2/5] VFS: Add VFS helper functions for setting up private namespaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1245792589.5133.24.camel@heimdal.trondhjem.org>
Date:	Tue, 23 Jun 2009 17:29:49 -0400
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] VFS: Add VFS helper functions for setting up
 private namespaces

On Tue, 2009-06-23 at 15:13 -0500, Serge E. Hallyn wrote:
> Quoting Trond Myklebust (Trond.Myklebust@...app.com):
> > The purpose of this patch is to improve the remote mount path lookup
> > support for distributed filesystems such as the NFSv4 client.
> > 
> > When given a mount command of the form "mount server:/foo/bar /mnt", the
> > NFSv4 client is required to look up the filehandle for "server:/", and
> > then look up each component of the remote mount path "foo/bar" in order
> > to find the directory that is actually going to be mounted on /mnt.
> > Following that remote mount path may involve following symlinks,
> > crossing server-side mount points and even following referrals to
> > filesystem volumes on other servers.
> > 
> > Since the standard VFS path lookup code already supports walking paths
> > that contain all these features (using in-kernel automounts for
> > following referrals) we would like to be able to reuse that rather than
> > duplicate the full path traversal functionality in the NFSv4 client code.
> > 
> > This patch therefore defines a VFS helper function create_mnt_ns(), that
> > sets up a temporary filesystem namespace and attaches a root filesystem to
> > it. It exports the create_mnt_ns() and put_mnt_ns() function for use by
> > filesystem modules.
> > 
> > Signed-off-by: Trond Myklebust <Trond.Myklebust@...app.com>
> 
> This looks good, thanks.  Though I see no reason not to also switch over
> init_mount_tree() to the new helper.
> 
> (Seems plausible that c/r code would use this as well)
> 
> Reviewed-by: Serge Hallyn <serue@...ibm.com>
> 
> thanks,
> -serge

Thanks for the review! I missed the code duplication in
init_mount_tree(). Something like the following?

Cheers
  Trond
--------------------------------------------------------------------
From: Trond Myklebust <Trond.Myklebust@...app.com>
VFS: Switch init_mount_tree() to use the new create_mnt_ns() helper

Eliminates some duplicated code...

Signed-off-by: Trond Myklebust <Trond.Myklebust@...app.com>
---

 fs/namespace.c |   11 ++---------
 1 files changed, 2 insertions(+), 9 deletions(-)


diff --git a/fs/namespace.c b/fs/namespace.c
index a7bea8c..4a86b85 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2222,16 +2222,9 @@ static void __init init_mount_tree(void)
 	mnt = do_kern_mount("rootfs", 0, "rootfs", NULL);
 	if (IS_ERR(mnt))
 		panic("Can't create rootfs");
-	ns = kmalloc(sizeof(*ns), GFP_KERNEL);
-	if (!ns)
+	ns = create_mnt_ns(mnt);
+	if (IS_ERR(ns))
 		panic("Can't allocate initial namespace");
-	atomic_set(&ns->count, 1);
-	INIT_LIST_HEAD(&ns->list);
-	init_waitqueue_head(&ns->poll);
-	ns->event = 0;
-	list_add(&mnt->mnt_list, &ns->list);
-	ns->root = mnt;
-	mnt->mnt_ns = ns;
 
 	init_task.nsproxy->mnt_ns = ns;
 	get_mnt_ns(ns);


-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/