public inbox for fsverity@lists.linux.dev
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: fstests@vger.kernel.org
Cc: fsverity@lists.linux.dev
Subject: [xfstests PATCH] generic/574: test corruption at more offsets
Date: Tue, 11 Jun 2024 20:53:34 -0700	[thread overview]
Message-ID: <20240612035334.134434-1-ebiggers@kernel.org> (raw)

From: Eric Biggers <ebiggers@google.com>

Expand generic/574 to test for corruption in more different parts of the
file to try to exercise any hashing optimizations that might be used.

There is no existing bug that this finds.  This is just to prevent
future bugs, considering optimizations along the lines of
https://lore.kernel.org/fsverity/20240611034822.36603-7-ebiggers@kernel.org/

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 tests/generic/574 | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/tests/generic/574 b/tests/generic/574
index cb42baaa..72440d49 100755
--- a/tests/generic/574
+++ b/tests/generic/574
@@ -194,10 +194,25 @@ test_block_size()
 	corruption_test $block_size 131072 0 5
 	corruption_test $block_size 131072 4091 5
 	corruption_test $block_size 131072 65536 65536
 	corruption_test $block_size 131072 131067 5
 
+	# Test corrupting a block in files of length 1..4 blocks, and test
+	# corrupting each block of a 4-block file.  This ensures that all code
+	# paths that might exist due to multi-block hashing optimizations the
+	# fsverity implementation may use get covered, assuming no more than 4
+	# blocks are hashed at once.  E.g., consider an fsverity implementation
+	# that verifies sets of blocks but has a bug when given a single block,
+	# or that has a bug that makes it not verify all the blocks of each set.
+	local i
+	for i in $(seq 1 4); do
+		corruption_test $block_size $((i*block_size)) $((block_size/2)) 5
+	done
+	for i in $(seq 0 3); do
+		corruption_test $block_size $((4*block_size)) $((i*block_size)) 5
+	done
+
 	corrupt_eof_block_test $block_size 130999 72
 
 	# Merkle tree corruption.
 	corruption_test $block_size 200000 100 10 true
 

base-commit: e46fa3a7dae4a65fd80128bf381dba4fd5036ebb
-- 
2.45.2


             reply	other threads:[~2024-06-12  3:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-12  3:53 Eric Biggers [this message]
2024-06-19 12:49 ` [xfstests PATCH] generic/574: test corruption at more offsets Andrey Albershteyn
2024-06-21  4:52   ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240612035334.134434-1-ebiggers@kernel.org \
    --to=ebiggers@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=fsverity@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox