Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: nfsd dead loop when xfstests generic/531
Date:   Tue, 1 Jun 2021 16:55:35 +0000
From:   Frank van der Linden <fllinden@amazon.com>
To:     Wang Yugui <wangyugui@e16-tech.com>
CC:     <linux-nfs@vger.kernel.org>
Message-ID: <20210601165535.GA3102@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com>
References: <20210531125948.2D37.409509F4@e16-tech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20210531125948.2D37.409509F4@e16-tech.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Mon, May 31, 2021 at 12:59:51PM +0800, Wang Yugui wrote:
> 
> 
> Hi,
> 
> nfsd dead loop when xfstests generic/531
> 
> linux kernel of nfs server: 5.10.41
> linux kernel of nfs client: 5.10.41
> 
> 
> nfsd dead loop when xfstests generic/531
> 
> linux kernel of nfs server: 5.10.41
> linux kernel of nfs client: 5.10.41

This is a known issue. generic/531 opens a large number of files, causing
the nfsd file cache code to walk a very long LRU list of open files. For
v4, there will be a lot of long term opens (because of the OPEN call),
and they all end up on that list.

So, the basic issue is, that the nfsd file cache is a good match for
v3 semantics, but less so for v4 semantics.

I posted an experimental patch to work around the issue:

https://lore.kernel.org/linux-nfs/20201020183718.14618-4-trondmy@kernel.org/T/#m869aa427f125afee2af9a89d569c6b98e12e516f

The rhashtable patch has issues, so disregard that one, but the other one
is a basic fix for this issue. It has one other issue that I noticed (refcount
error), but that is easily fixed.

I should update the patch and formally post it..

- Frank