[REGRESSION] loop: use vfs_getattr_nosec for accurate file size

[REGRESSION] loop: use vfs_getattr_nosec for accurate file size

[Theodore Ts'o]

Hi, I was testing 6.17-rc3, and I noticed a test failure in fstest
generic/563[1], when testing both ext4 and xfs.  If you are using my
test appliance[2], this can be trivially reproduced using:

   kvm-xfstests -c ext4/4k generic/563
or
   kvm-xfstests -c xfs/4k generic/563

[1] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/generic/563
[2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md

A git bisect pointed the problem at:

commit 47b71abd58461a67cae71d2f2a9d44379e4e2fcf
Author: Rajeev Mishra <rajeevm@hpe.com>
Date:   Mon Aug 18 18:48:21 2025 +0000

    loop: use vfs_getattr_nosec for accurate file size
    
    Use vfs_getattr_nosec() in lo_calculate_size() for getting the file
    size, rather than just read the cached inode size via i_size_read().
    This provides better results than cached inode data, particularly for
    network filesystems where metadata may be stale.
    
    Signed-off-by: Rajeev Mishra <rajeevm@hpe.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20250818184821.115033-3-rajeevm@hpe.com
    [axboe: massage commit message]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

... and indeed if I go to 6.17-rc3, and revert this commit,
generic/563 starts passing again.

Could you please take a look, and/or revert this change?  Many thanks!

      	  	      	      	 	- Ted

Re: [REGRESSION] loop: use vfs_getattr_nosec for accurate file size

[Yi Zhang]

Hi Theodore

It should be fixed by this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-next&id=d14469ed7c00314fe8957b2841bda329e4eaf4ab

On Wed, Aug 27, 2025 at 11:00 AM Theodore Ts'o <tytso@mit.edu> wrote:
>
> Hi, I was testing 6.17-rc3, and I noticed a test failure in fstest
> generic/563[1], when testing both ext4 and xfs.  If you are using my
> test appliance[2], this can be trivially reproduced using:
>
>    kvm-xfstests -c ext4/4k generic/563
> or
>    kvm-xfstests -c xfs/4k generic/563
>
> [1] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/generic/563
> [2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
>
> A git bisect pointed the problem at:
>
> commit 47b71abd58461a67cae71d2f2a9d44379e4e2fcf
> Author: Rajeev Mishra <rajeevm@hpe.com>
> Date:   Mon Aug 18 18:48:21 2025 +0000
>
>     loop: use vfs_getattr_nosec for accurate file size
>
>     Use vfs_getattr_nosec() in lo_calculate_size() for getting the file
>     size, rather than just read the cached inode size via i_size_read().
>     This provides better results than cached inode data, particularly for
>     network filesystems where metadata may be stale.
>
>     Signed-off-by: Rajeev Mishra <rajeevm@hpe.com>
>     Reviewed-by: Yu Kuai <yukuai3@huawei.com>
>     Link: https://lore.kernel.org/r/20250818184821.115033-3-rajeevm@hpe.com
>     [axboe: massage commit message]
>     Signed-off-by: Jens Axboe <axboe@kernel.dk>
>
> ... and indeed if I go to 6.17-rc3, and revert this commit,
> generic/563 starts passing again.
>
> Could you please take a look, and/or revert this change?  Many thanks!
>
>                                         - Ted
>


-- 
Best Regards,
  Yi Zhang

Re: [REGRESSION] loop: use vfs_getattr_nosec for accurate file size

[Yu Kuai]

Hi,

在 2025/08/27 10:59, Theodore Ts'o 写道:
> Hi, I was testing 6.17-rc3, and I noticed a test failure in fstest
> generic/563[1], when testing both ext4 and xfs.  If you are using my
> test appliance[2], this can be trivially reproduced using:
> 
>     kvm-xfstests -c ext4/4k generic/563
> or
>     kvm-xfstests -c xfs/4k generic/563
> 
> [1] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/generic/563
> [2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
> 
> A git bisect pointed the problem at:
> 
> commit 47b71abd58461a67cae71d2f2a9d44379e4e2fcf
> Author: Rajeev Mishra <rajeevm@hpe.com>
> Date:   Mon Aug 18 18:48:21 2025 +0000
> 
>      loop: use vfs_getattr_nosec for accurate file size
>      
>      Use vfs_getattr_nosec() in lo_calculate_size() for getting the file
>      size, rather than just read the cached inode size via i_size_read().
>      This provides better results than cached inode data, particularly for
>      network filesystems where metadata may be stale.
>      
>      Signed-off-by: Rajeev Mishra <rajeevm@hpe.com>
>      Reviewed-by: Yu Kuai <yukuai3@huawei.com>
>      Link: https://lore.kernel.org/r/20250818184821.115033-3-rajeevm@hpe.com
>      [axboe: massage commit message]
>      Signed-off-by: Jens Axboe <axboe@kernel.dk>
> 
> ... and indeed if I go to 6.17-rc3, and revert this commit,
> generic/563 starts passing again.
> 
> Could you please take a look, and/or revert this change?  Many thanks!

This is fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=block-6.17&id=d14469ed7c00314fe8957b2841bda329e4eaf4ab

Thanks,
Kuai

> 
>        	  	      	      	 	- Ted
> 
> .
> 

Re: [REGRESSION] loop: use vfs_getattr_nosec for accurate file size

[Theodore Ts'o]

On Wed, Aug 27, 2025 at 11:13:13AM +0800, Yu Kuai wrote:
> This is fixed by:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=block-6.17&id=d14469ed7c00314fe8957b2841bda329e4eaf4ab

Great, thanks!  Looking forward to this landing in linux-next (since
it showed up in my automated linux-next testing laght night).

Thanks,

						- Ted

Re: [REGRESSION] loop: use vfs_getattr_nosec for accurate file size

[Jens Axboe]

On 8/27/25 8:31 AM, Theodore Ts'o wrote:
> On Wed, Aug 27, 2025 at 11:13:13AM +0800, Yu Kuai wrote:
>> This is fixed by:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=block-6.17&id=d14469ed7c00314fe8957b2841bda329e4eaf4ab
> 
> Great, thanks!  Looking forward to this landing in linux-next (since
> it showed up in my automated linux-next testing laght night).

Sorry about that, the patch was queued for linux-next on my end on Monday.
Surprised it isn't there already - in any case, it will be soon.

-- 
Jens Axboe