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.
#regzbot introduced: 7378c7adf31d
Thanks, Aaron Ahmed
[1] https://lore.kernel.org/all/20210414134353.11860-1-trondmy@kernel.org/
Signed-off-by: Aaron Ahmed aarnhahmd@amazon.com
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
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.
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")
linux-stable-mirror@lists.linaro.org
-
Ahmed, Aaron -
gregkh＠linuxfoundation.org -
Trond Myklebust