On Mon, 2 Dec 2013 11:37:35 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Mon, Dec 02, 2013 at 11:33:19AM -0500, Jeff Layton wrote: > > On Mon, 2 Dec 2013 11:00:50 -0500 > > Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > > > > > > > On Dec 2, 2013, at 10:34, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > > On Mon, Dec 02, 2013 at 08:44:25AM -0500, Trond Myklebust wrote: > > > >> The lifetime of the kernel mount only needs to match that of the rpc_client, since each rpc_client is associated to a single net namespace, and each net namespace is in a 1-1 relationship with an rpc_pipefs super block. > > > > > > > > Except for the non-rpc_client users of rpc_pipefs? > > > > > > There is the idmapper pipe which is created as part of setting up a NFSv4 mount: that could either call rpc_get_mount(), or just rely on the fact that the nfs_client has an rpc_client. Ditto for the DNS resolver pipe. > > > > > > Any more? > > > > > > > There's the nfsdcld pipe stuff, but that was supposed to have been > > ripped out in 3.10. Bruce wasn't ready to do that since we didn't have > > a solution to the problem of using a UMH upcall in a container. > > > > As far as I'm concerned, we should go ahead and rip that out and worry > > about the UMH in a container problem later. Bruce, any objection to > > going ahead and doing that? I can respin/resend the patch to do that if > > you're ready for it... > > I still haven't seen a solution to the UMH problem. Do we even expect > that there will be one at this point? > > I just want to avoid the worst case where we decide that UMH was just > not designed for this kind of upcall, period, and then need to backtrack > again.... > I don't think there's a solution as of yet... I'd like to avoid that too, but I expect that no one is actually using that code anyway. If we have to put it back in (ugh) then we'll probably need to rethink parts of it anyhow. I'm not aware of any distro that ever shipped with it enabled. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
