Re: [PATCH v4] fstests: generic: add a test case to check fsverity reads

[Dhruva G <goledhruva@gmail.com>]

On 17-10-2026 14:33, Qu Wenruo wrote:
> There is a bug report that with the recently enabled large folios
> support, fsverity enabled files on btrfs can trigger reproducible
> warnings about file corruption, but in the end no error is returned to
> user space.
> 
> It turns out to be a bug in the btrfs fsverity integration, where blocks
> not included in the read range are passed to be verified.
> 
> This is a long-standing bug where btrfs fsverity always assumed that one
> folio contains exactly one fs block, ignoring the fact that btrfs had
> block size < page size support before fsverity support was added.
> 
> Add a new regression test case for it. The workload is pretty simple:
> 
> - Create a 32M file
> 
> - Punch a 64K hole for every 128K
>   This will limit the read bio size to 64K, which is smaller than
>   a lot of large folios, and thus can trigger the btrfs bug.
> 
> - Enable fsverity digest and drop page cache
> 
> - Read that file and verify its content
> 
> - Verify there is no "FILE CORRUPTED!" warning
> 
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> Changelog
> v4:
> - Also output the checksum for the file for content verification
> 
> - Update the comment to show the requirement more clearly
>   It requires the folio size larger than the fs block size.
> 
>   This means either a system with larger page size (e.g. 64K page sized
>   arm64 with 4K block size), or large folio support (which requires
>   transparent huge page).
> 
> - Minor comment updates
>   * Concentrate the mention of large folio to the triggering part
>   * Explain why fserror is not utilized for error detection
For this version too,

Reviewed-by: Dhruva Gole <goledhruva@gmail.com>
Tested-by: Dhruva Gole <goledhruva@gmail.com>