Return-Path: linux-nfs-owner@vger.kernel.org Received: from fieldses.org ([174.143.236.118]:33093 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752311Ab3LBQiB (ORCPT ); Mon, 2 Dec 2013 11:38:01 -0500 Date: Mon, 2 Dec 2013 11:37:35 -0500 From: "J. Bruce Fields" To: Jeff Layton Cc: Trond Myklebust , Christoph Hellwig , Viro Alexander , Linux NFS Mailing List , Devel FS Linux , Torvalds Linus , Eric Biederman Subject: Re: [PATCH 00/11] [RFC] repair net namespace damage to rpc_pipefs Message-ID: <20131202163735.GK1960@fieldses.org> References: <20131201131441.790963326@bombadil.infradead.org> <20131201181329.GC10323@ZenIV.linux.org.uk> <20131202081233.GA6953@infradead.org> <3C65EB4C-6592-44F8-B08D-E5A9EFD6C8C6@primarydata.com> <20131202153435.GA2804@infradead.org> <20131202113319.36ac5332@tlielax.poochiereds.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20131202113319.36ac5332@tlielax.poochiereds.net> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Mon, Dec 02, 2013 at 11:33:19AM -0500, Jeff Layton wrote: > On Mon, 2 Dec 2013 11:00:50 -0500 > Trond Myklebust wrote: > > > > > On Dec 2, 2013, at 10:34, Christoph Hellwig 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.