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? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
