linux-kernel - Re: [PATCH RFC 0/9] nfs/sunrpc: stop holding netns references in client-side NFS and RPC objects

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <05463008488b1fea6fb47a2d1a525096fecda861.camel@kernel.org>
Date: Mon, 17 Mar 2025 17:57:53 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Trond Myklebust <trondmy@...merspace.com>, "horms@...nel.org"	
 <horms@...nel.org>, "davem@...emloft.net" <davem@...emloft.net>, 
 "chuck.lever@...cle.com"	 <chuck.lever@...cle.com>, "okorniev@...hat.com"
 <okorniev@...hat.com>,  "anna@...nel.org"	 <anna@...nel.org>,
 "kuba@...nel.org" <kuba@...nel.org>, "tom@...pey.com"	 <tom@...pey.com>,
 "Dai.Ngo@...cle.com" <Dai.Ngo@...cle.com>, "neilb@...e.de"	
 <neilb@...e.de>, "edumazet@...gle.com" <edumazet@...gle.com>, 
 "pabeni@...hat.com"	 <pabeni@...hat.com>
Cc: "josef@...icpanda.com" <josef@...icpanda.com>, 
 "linux-nfs@...r.kernel.org"
	 <linux-nfs@...r.kernel.org>, "bcodding@...hat.com" <bcodding@...hat.com>, 
 "linux-kernel@...r.kernel.org"
	 <linux-kernel@...r.kernel.org>, "netdev@...r.kernel.org"
	 <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC 0/9] nfs/sunrpc: stop holding netns references in
 client-side NFS and RPC objects

On Mon, 2025-03-17 at 21:35 +0000, Trond Myklebust wrote:
> On Mon, 2025-03-17 at 16:59 -0400, Jeff Layton wrote:
> > We have a long-standing problem with containers that have NFS mounts
> > in
> > them. Best practice is to unmount gracefully, of course, but
> > sometimes
> > containers just spontaneously die (e.g. SIGSEGV in the init task in
> > the
> > container). When that happens the orchestrator will see that all of
> > the
> > tasks are dead, and will detach the mount namespace and kill off the
> > network connection.
> > 
> > If there are RPCs in flight at the time, the rpc_clnt will try to
> > retransmit them indefinitely, but there is no hope of them ever
> > contacting the server since nothing in userland can reach the netns
> > at that point to fix anything.
> > 
> > This patchset takes the approach of changing various nfs client and
> > sunrpc objects to not hold a netns reference. Instead, when a nfs_net
> > or
> > sunrpc_net is exiting, all nfs_server, nfs_client and rpc_clnt
> > objects
> > associated with it are shut down, and the pre_exit functions block
> > until they are gone.
> > 
> > With this approach, when the last userland task in the container
> > exits,
> > the NFS and RPC clients get cleaned up automatically. As a bonus,
> > this
> > fixes another bug with the gssproxy RPC client that causes net
> > namespace
> > leaks in any container where it runs (details in the patch
> > descriptions).
> > 
> 
> So with this approach, what happens if the NFS mount was created in a
> container, but got bind mounted somewhere else?
> 

The lifetime of these objects are tied to the net namespace. If it gets
bind-mounted into a different mount namespace, while the tasks are
setns()'ed into the correct net namespace, then I expect the mount
would end up shut down at that point and be unusable, just like if you
echo 1 into the shutdown file in sysfs.

Hopefully no one is doing anything that silly. You wouldn't be able to
upcall, for one thing, since there wouldn't be any more userland
processes attached to the netns.

I'll test that scenario and get back to you though. I do want to make
sure that that's not going to lead to a crash or anything.
-- 
Jeff Layton <jlayton@...nel.org>