Hi,

quoted

On Jan 13, 2023, at 09:41, Chuck Lever III [off-list ref] wrote:

quoted

On Jan 12, 2023, at 4:30 AM, Wang Yugui [off-list ref] wrote:

Hi,

quoted

Hi,

quoted

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@e16-tech.com)
2023/01/11

quoted

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?

In the case, 'df -h' will fail to work without the 'umount -l'.

so I thought we should make 'umount -l' to works.

Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2023/01/14