Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 14 Jan 2023 01:00:31 +0800
From:   Wang Yugui <wangyugui@e16-tech.com>
To:     Chuck Lever III <chuck.lever@oracle.com>
Subject: Re: a dead lock of 'umount.nfs4 /nfs/scratch -l'
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
In-Reply-To: <5B9215E4-99FF-4C52-901F-8D909DD165BD@oracle.com>
References: <20230112173046.82E4.409509F4@e16-tech.com> <5B9215E4-99FF-4C52-901F-8D909DD165BD@oracle.com>
Message-Id: <20230114010030.D461.409509F4@e16-tech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

> > On Jan 12, 2023, at 4:30 AM, Wang Yugui <wangyugui@e16-tech.com> 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@e16-tech.com)
> >> 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?

Just the 'mount -l' is stuck.
'Ctrl +C' can stop the 'mount -l', and then the mount point disapear.

> - Can you reproduce in a non-loopback scenario: a separate client and
>   server?

Yes. It happened on separate nfs client and  server too.

tested kernel version: 5.15.85, 6.1.5, 6.2.0-rc3+(upstream)

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