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.... --b. -- 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
