On Fri, Jan 07, 2011 at 01:12:22PM +0200, Kirill A. Shutemov wrote:
> On Wed, Jan 05, 2011 at 11:41:55AM +0000, Al Viro wrote:
> > On Wed, Dec 29, 2010 at 03:14:18PM +0200, Kirill A. Shutemov wrote:
> > > Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
> >
> > Won't that make sunrpc impossible to rmmod once you've got it in?
> > Note that having a reference to vfsmount pins it down, which pins
> > the superblock down, which pins the file_system_type down, which
> > pins the damn module down. So cleanup_sunrpc() won't be ever called,
> > AFAICS...
>
> Hm.. rpc_pipe_fs_type.owner = NULL seems fix the problem.
> Is it valid solution in this case?

Please, ignore it. :)

--
Kirill A. Shutemov

2011-01-03 16:53:57

by Kirill A. Shutemov

[permalink] [raw]

Subject: Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time

On Fri, Dec 31, 2010 at 03:03:29PM +0200, Kirill A. Shutemov wrote:
> On Thu, Dec 30, 2010 at 06:52:43AM -0600, Rob Landley wrote:
> > On 12/30/2010 05:45 AM, Kirill A. Shutemov wrote:
> > > Currently, there is no association between rpc_pipefs and mount namespace,
> >
> > There is in that the root context doesn't need to have this mounted, and
> > new namespaces do. So there's an existing association between a LACK of
> > a namespace and a different default behavior.
> >
> > My understanding (correct me if I'm wrong) is that the historical
> > behavior is that there's only one, and it doesn't actually live anywhere
> > in the filesystem tree. You're adding a special location. I'm
> > wondering if there's any way for that location not to be special.
>
> /var/lib/net/rpc_pipefs is default path where userspace part of NFS stack
> (gssd, idmapd) want to see rpc_pipefs
>
> > > so I don't see simple way to restrict number of rpc_pipefs per mount
> > > namespace. Associating mount namespace with rpc_pipefs is not a good idea,
> > > I think.
> >
> > I'm talking about associating a default rpc_pipefs instance with a
> > namespace, which it seems to me you're already doing by emulating the
> > legacy behavior. Before you CLONE_NEWNS you get a magic default mount
> > that doesn't exist in the tree. After you CLONE_NEWNS you get something
> > like -EINVAL unless you supply your own default.
>
> Root namespace is special. In case of nfsroot you need rpc_pipefs before
> root available.
>
> > (I'm actually not sure
> > why new namespaces don't fall back to the magic global one...)
>
> It breaks isolation. Container should not use host's rpc_pipefs without
> host's permission.
>
> > I'm suggesting that if the user doesn't specify -o rpcmount then the
> > default could be the first rpc_pipefs mount visible to the current
> > process context, rather than a specific path. Logic to do that exists
> > in the proc/self/mounts code (which I'm reading through now...).
>
> static int check_rpc_pipefs(struct vfsmount *mnt, void *arg)
> {
> struct vfsmount **rpcmount = arg;
> struct path path = {
> .mnt = mnt,
> .dentry = mnt->mnt_root,
> };
>
> if (!mnt->mnt_sb)
> return 0;
> if (mnt->mnt_sb->s_magic != RPCAUTH_GSSMAGIC)
> return 0;
>
> if (!path_is_under(&path, &current->fs->root))
> return 0;
>
> *rpcmount = mntget(mnt);
> return 1;
> }
>
> struct vfsmount *get_rpc_pipefs(const char *p)
> {
> int error;
> struct vfsmount *rpcmount = ERR_PTR(-EINVAL);
> struct path path;
>
> if (!p) {
> iterate_mounts(check_rpc_pipefs, &rpcmount,
> current->nsproxy->mnt_ns->root);
>
> if (IS_ERR(rpcmount) && (current->nsproxy->mnt_ns ==
> init_task.nsproxy->mnt_ns))
> return mntget(init_rpc_pipefs);
>
> return rpcmount;
> }
>
> error = kern_path(p, LOOKUP_FOLLOW | LOOKUP_DIRECTORY, &path);
> if (error)
> return ERR_PTR(error);
>
> check_rpc_pipefs(path.mnt, &rpcmount);
> path_put(&path);
>
> return rpcmount;
> }
> EXPORT_SYMBOL_GPL(get_rpc_pipefs);
>
> Something like this? Patch to replace patch #10 attached.

Any comments?

--
Kirill A. Shutemov