FS/XFS testing framework
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Andrey Albershteyn <aalbersh@redhat.com>
Cc: fstests@vger.kernel.org, fsverity@lists.linux.dev
Subject: Re: [xfstests PATCH] generic/574: test corruption at more offsets
Date: Thu, 20 Jun 2024 21:52:22 -0700	[thread overview]
Message-ID: <20240621045222.GD4362@sol.localdomain> (raw)
In-Reply-To: <rgy632iwsrbmwoiquqosutpj6wsfua3jzhcgb4eac4hz2zuqm5@f5qbqkh4qjae>

On Wed, Jun 19, 2024 at 02:49:23PM +0200, Andrey Albershteyn wrote:
> On 2024-06-11 20:53:34, Eric Biggers wrote:
> > 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
> > 
> > 
> 
> The addition looks fine to me, why is it 4 blocks though, isn't 2
> enough?
> 
> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
> 

For the currently proposed fsverity patch, 2 is enough.  The same approach could
be extended to more blocks later, though.  So using something a bit higher in
the test from the beginning makes sense.

- Eric

      reply	other threads:[~2024-06-21  4:52 UTC|newest]

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

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=20240621045222.GD4362@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=aalbersh@redhat.com \
    --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