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

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Oct 16, 2026 at 07:24:32PM +1030, Qu Wenruo wrote:
> 
> 
> 在 2026/10/16 18:54, Eric Biggers 写道:
> > On Fri, Oct 16, 2026 at 06:35:05PM +1030, Qu Wenruo wrote:
> > > 
> > > 
> > > 在 2026/10/16 18:17, Eric Biggers 写道:
> > > > On Mon, Oct 12, 2026 at 08:56:13AM +1030, Qu Wenruo wrote:
> > > > > +_fixed_by_fs_commit btrfs xxxxxxxxxxxx \
> > > > > +	"btrfs: fix the fsverity callback where unexpected range is verified"
> > > > 
> > > > Even without that commit, 'kvm-xfstests -c btrfs generic/807' still
> > > > passes.  Under what circumstances will this test fail?
> > > 
> > > It need as least 7.2 upstream, which enables large data folios for btrfs by
> > > default.
> > > 
> > > And I can always reproduce it here, mind to provide more info about the
> > > passed run?
> > 
> > This is on the latest mainline (2f2f7eeef8b0).  Not sure what else
> > you're looking for.
> 
> It can be racy, since the fsverity call is at endio time, if all the endio
> of the same large folio is called after all the reads of the folio finished,
> it can also pass the verification.
> 
> But I don't think it's that possible, unless you have blazing fast storage.
> As the first hole read should trigger the verification for the whole folio
> and trigger an fsverity error immediately.
> 
> I can enlarge the file size, or even git it a loop to run multiple times,
> but I just can't figure out why...
> 
> Or is it possible that the kernel config doesn't have
> CONFIG_TRANSPARENT_HUGEPAGE?

Indeed, I didn't have CONFIG_TRANSPARENT_HUGEPAGE enabled.  Enabling it
makes the test fail as expected.  Maybe would be helpful to mention that
prerequisite in a comment in the test.

- Eric