> On Jan 13, 2023, at 09:41, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > >> On Jan 12, 2023, at 4:30 AM, Wang Yugui <wangyugui@xxxxxxxxxxxx> wrote: >> >> Hi, >> >>> Hi, >>> >>>> Hi, >>>> >>>> We noticed a dead lock of 'umount.nfs4 /nfs/scratch -l' >>> >>> reproducer: >>> >>> mount /dev/sda1 /mnt/test/ >>> mount /dev/sda2 /mnt/scratch/ >>> systemctl restart nfs-server.service >>> mount.nfs4 127.0.0.1:/mnt/test/ /nfs/test/ >>> mount.nfs4 127.0.0.1:/mnt/scratch/ /nfs/scratch/ >>> systemctl stop nfs-server.service >>> umount -l /nfs/scratch #OK >>> umount -l /nfs/test #dead lock >>> >>> Best Regards >>> Wang Yugui (wangyugui@xxxxxxxxxxxx) >>> 2023/01/11 >>> >>>> kernel: 6.1.5-rc1 >> >> This problem happen on kernel 6.2.0-rc3+(upstream) too. > > Can you clarify: > > - By "deadlock" do you mean the system becomes unresponsive, or that > just the mount is stuck? > > - Can you reproduce in a non-loopback scenario: a separate client and > server? > I’m not seeing how the use of the ‘-l’ flag is at all relevant here. The exact same thing will happen if you don’t use ‘-l’. All the latter does is hide the fact that it is happening from user space. As far as I’m concerned, this is pretty much expected behaviour when you turn off the server before unmounting. It means that the client can’t flush any remaining dirty data to the server and it can’t clean up state. So just don’t do that? _________________________________ Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
