[PATCH] fstests: btrfs: add a test case to verify fsverity on compressed files

[Qu Wenruo <wqu@suse.com>]

There is a bug report that with the recently enabled large folios
support, compressed files on btrfs can give random but reproducible
warnings about file corruption.

It turns out to be a bug in the verification range, where blocks not
included in the read range are passed to be verified.

Add a new regression test case for it, the workload is pretty simple:

- Create a 64M file with compressed file extents
- Enable fsverity digest on that file
- Drop page cache
- Read that file
- Verify there is no "FILE CORRUPTED!" warning

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 tests/btrfs/359     | 45 +++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/359.out |  6 ++++++
 2 files changed, 51 insertions(+)
 create mode 100755 tests/btrfs/359
 create mode 100644 tests/btrfs/359.out

diff --git a/tests/btrfs/359 b/tests/btrfs/359
new file mode 100755
index 00000000..2047d965
--- /dev/null
+++ b/tests/btrfs/359
@@ -0,0 +1,45 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 SUSE S.A.  All Rights Reserved.
+#
+# FS QA Test 359
+#
+# Test if btrfs handles fsverity read correctly without corruption warning
+#
+. ./common/preamble
+_begin_fstest auto quick verity compress
+
+_fixed_by_kernel_commit xxxxxxxxxxxx \
+	"btrfs: fix the fsverity callback where unexpected range is verified"
+
+. ./common/filter
+. ./common/verity
+
+_require_scratch_verity
+
+_scratch_mkfs_verity >> $seqres.full
+
+# We need a read range that doesn't cover the full folio, the easiest way
+# to create such read is compression, which limits the extent size to 128K,
+# much smaller than the supported large folio size (256K or 2M for 4K page size).
+_scratch_mount -o compress
+
+# Create a large enough file that can contain multiple compressed file extents.
+_pwrite_byte "0xcd" 0 64m "$SCRATCH_MNT/foobar" | _filter_xfs_io
+
+# Enable verity on that file
+_fsv_enable "$SCRATCH_MNT/foobar"
+
+# Cycle mount to drop page cache
+_scratch_cycle_mount
+
+# Read the file, unpatched kernel will race and trigger fs-verity warnings.
+# But the read itself should still be fine, as the failed part will be retried.
+_hexdump "$SCRATCH_MNT/foobar"
+
+# Check for any kernel warnings from fs-verity on file corruption.
+if _check_dmesg_for "FILE CORRUPTED!"; then
+	echo "fs-verity detected corruption"
+fi
+
+_exit 0
diff --git a/tests/btrfs/359.out b/tests/btrfs/359.out
new file mode 100644
index 00000000..96bd78d7
--- /dev/null
+++ b/tests/btrfs/359.out
@@ -0,0 +1,6 @@
+QA output created by 359
+wrote 67108864/67108864 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+000000 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  >................<
+*
+4000000
-- 
2.56.0