> On Sep 6, 2024, at 5:56 PM, NeilBrown <neilb@xxxxxxx> wrote: > > We could achieve the same effect without using symbol_request() (which > hardly anyone uses) if we did a __module_get (or try_module_get) at the > same place you are calling symbol_request(), and module_put() where you > do symbol_put(). > > This would mean that once NFS LOCALIO had detected a path to the local > server, it would hold the nfsd module until the nfs server were shutdown > and the nfs client noticed. So you wouldn't be able to unmount the nfsd > module immediately after stopping all nfsd servers. > > Maybe that doesn't matter. I think it is important to be able to > completely shut down the NFS server at any time. I think it is > important to be able to completely shutdown a network namespace at any > time. I am less concerned about being able to rmmod the nfsd module > after all obvious users have been disabled. > > So if others think that the improvements in code maintainability are > worth the loss of being able to rmmod nfsd without (potentially) having > to unmount all NFS filesystems, then I won't argue against it. But I > really would want it to be get/put of the module, not of some symbol. The client and server are potentially in separate containers, administered independently. An NFS mount should not pin either the NFS server's running status, its ability to unexport a shared file system, the ability for the NFS server's administrator to rmmod nfsd.ko, the ability for the administrator to rmmod a network device that is in use by the NFS server, or the ability to destroy the NFS server's namespace once NFSD has shut down. I don't feel that this is a code maintainability issue, but rather this is a usability and security mandate. Remote NFS mounts don't (or, are not supposed to) pin NFSD's resources in any way. That is the behavioral standard, and if we find that is not the case, we treat it as a bug. TL;DR: it does matter. LOCALIO NFS mounts should not indefinitely pin NFSD or its resources. -- Chuck Lever
