Re: [REGRESSION] nfs: Large amounts of GETATTR calls after file renaming on v5.10.241

["gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>]

On Sat, Nov 22, 2025 at 10:43:29AM -0500, Trond Myklebust wrote:
> On Sat, 2025-11-22 at 07:56 +0100, gregkh@linuxfoundation.org wrote:
> > On Fri, Nov 21, 2025 at 06:56:31PM +0000, Ahmed, Aaron wrote:
> > > Hi,
> > > 
> > > We have had customers report a regression on kernels versions
> > > 5.10.241 and above in which file renaming causes large amounts of
> > > GETATTR calls to made due to inode revalidation. This regression
> > > was pinpointed via bisected to commit 7378c7adf31d ("NFS: Don't set
> > > NFS_INO_REVAL_PAGECACHE in the inode cache validity") which is a
> > > backport of 36a9346c2252 (“NFS: Don't set NFS_INO_REVAL_PAGECACHE
> > > in the inode cache validity”). 
> > > 
> > > We were able to reproduce It with this script:
> > > REPRO_PATH=/mnt/efs/repro
> > > do_read()
> > > {
> > >     for x in {1..50}
> > >     do
> > >         cat $1 > /dev/null
> > >     done
> > >     grep GETATTR /proc/self/mountstats
> > > }
> > > 
> > > echo foo > $REPRO_PATH/bar
> > > echo "After create, before read:"
> > > grep GETATTR /proc/self/mountstats
> > > 
> > > echo "First read:"
> > > do_read $REPRO_PATH/bar
> > > 
> > > echo "Sleeping 5s, reading again (should look the same):"
> > > sleep 5
> > > do_read $REPRO_PATH/bar
> > > 
> > > mv $REPRO_PATH/bar $REPRO_PATH/baz
> > > echo "Moved file, reading again:"
> > > do_read $REPRO_PATH/baz
> > > 
> > > echo "Immediately performing another set of reads:"
> > > do_read $REPRO_PATH/baz
> > > 
> > > echo "Cleanup, removing test file"
> > > rm $REPRO_PATH/baz
> > > which performs a few read/writes. On kernels without the regression
> > > the number of GETATTR calls remains the same while on affected
> > > kernels the amount increases after reading renamed file. 
> > > 
> > > This original commit comes from a series of patches providing
> > > attribute revalidation updates [1].  However, many of these patches
> > > are missing in v.5.10.241+. Specifically, 13c0b082b6a9 (“NFS:
> > > Replace use of NFS_INO_REVAL_PAGECACHE when checking cache
> > > validity”) seems like a prerequisite patch and would help remedy
> > > the regression.
> > 
> > Can you please send the needed backports to resolve this issue as you
> > can test and verify that this resolves the problem?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Ah... If I'm correctly reading the changelog
> in https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.241, it
> looks as if commit 36a9346c2252 got pulled in by the stable patch
> automation as a dependency for commit b01f21cacde9 ("NFS: Fix the
> setting of capabilities when automounting a new filesystem").
> 
> I do agree with Aaron's assessment that patch does depend on the rest
> of the series that was merged into Linux 5.13. It cannot be cherry-
> picked on its own.
> 
> However what exactly was the dependency that caused it to be pulled
> into 5.10.241 in the first place? Was that logged anywhere?
> I just checked out v5.10.241 and applied "git revert --signoff
> 36a9346c2252", and that appears to work just fine, and I don't see any
> other obvious code dependency there, so I'm curious about what
> happened.

As the commit says:
	Stable-dep-of: b01f21cacde9 ("NFS: Fix the setting of capabilities when automounting a new filesystem")