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

[Kirill A. Shutemov]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/