Hi Bruce, Thanks for the clarifications. On Tue, Aug 27, 2019 at 11:51 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Tue, Aug 27, 2019 at 12:05:28PM +0300, Alex Lyakas wrote: > > Is the described issue familiar to you? > > Yep, got it, but I haven't seen anyone try to solve it using the fault > injection code, that's interesting! > > There's also fs/nfsd/unlock_filesystem. It only unlocks NLM (NFSv3) > locks. But it'd probably be reasonable to teach it to get NFSv4 state > too (locks, opens, delegations, and layouts). > > But my feeling's always been that the cleanest way to do it is to create > two containers with separate net namespaces and run nfsd in both of > them. You can start and stop the servers in the different containers > independently. I am looking at the code, and currently nfsd creates a single namespace subsystem in init_nfsd. All nfs4_clients run in this subsystem. So the proposal is to use register_pernet_subsys() for every filesystem that is exported? I presume that current nfsd code cannot do this, and some rework is required to move away from a single subsystem to per-export subsystem. Also, grepping through kernel code, I see that namespace subsystems are created by different modules as part of module initialization, rather than doing that dynamically. Furthermore, in our case the same nfsd machine S can export tens or even hundreds of local filesystems.Is this fine to have hundreds of subsystems? Otherwise, I understand that the current behavior is a "won't fix", and it is expected for the client machine to unmount the export before un-exporting the file system at nfsd machine. Is this correct? Thanks, Alex. > > > It is very easily reproducible. What is the way to solve it? To our > > understanding, if we un-export a FS from nfsd, we should be able to > > unmount it. > > Unexporting has never removed locks or opens or other state, for what > it's worth. > > --b.
