From: Boris Burkov <boris@bur.io>
To: Eric Biggers <ebiggers@kernel.org>
Cc: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v6 4/4] generic: test fs-verity EFBIG scenarios
Date: Tue, 15 Mar 2022 15:06:32 -0700 [thread overview]
Message-ID: <YjEN6AzzisfT9j7u@zen> (raw)
In-Reply-To: <Yi/2/isOZMX3Riww@gmail.com>
On Tue, Mar 15, 2022 at 02:16:30AM +0000, Eric Biggers wrote:
> On Mon, Feb 14, 2022 at 04:09:58PM -0800, Boris Burkov wrote:
> > diff --git a/tests/generic/690 b/tests/generic/690
> > new file mode 100755
> > index 00000000..77906dd8
> > --- /dev/null
> > +++ b/tests/generic/690
> > @@ -0,0 +1,66 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2021 Facebook, Inc. All Rights Reserved.
> > +#
> > +# FS QA Test 690
> > +#
> > +# fs-verity requires the filesystem to decide how it stores the Merkle tree,
> > +# which can be quite large.
> > +# It is convenient to treat the Merkle tree as past EOF, and ext4, f2fs, and
> > +# btrfs do so in at least some fashion. This leads to an edge case where a
> > +# large file can be under the file system file size limit, but trigger EFBIG
> > +# on enabling fs-verity. Test enabling verity on some large files to exercise
> > +# EFBIG logic for filesystems with fs-verity specific limits.
> > +#
> > +. ./common/preamble
> > +_begin_fstest auto quick verity
> > +
> > +
> > +# Import common functions.
> > +. ./common/filter
> > +. ./common/verity
> > +
> > +# real QA test starts here
> > +_supported_fs generic
> > +_require_test
> > +_require_math
> > +_require_scratch_verity
> > +_require_fsverity_max_file_size_limit
> > +_require_scratch_nocheck
>
> Why is _require_scratch_nocheck() needed? _require_scratch_verity() already
> does _require_scratch(), and I don't see why skipping fsck would be needed.
>
> > +# have to go back by 4096 from max to not hit the fsverity MAX_LEVELS check.
> > +truncate -s $max_sz $fsv_file
>
> The above comment should be removed.
>
Thanks for catching these oversights, will fix them. The nocheck thing
was left over from mixing/copy-pasting with btrfs/290 during this test's
evolution. Works fine without it on ext4 and btrfs.
> - Eric
prev parent reply other threads:[~2022-03-15 22:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-15 0:09 [PATCH v6 0/4] tests for btrfs fsverity Boris Burkov
2022-02-15 0:09 ` [PATCH v6 1/4] btrfs: test btrfs specific fsverity corruption Boris Burkov
2022-03-14 23:58 ` Eric Biggers
2022-03-15 22:02 ` Boris Burkov
2022-02-15 0:09 ` [PATCH v6 2/4] generic/574: corrupt btrfs merkle tree data Boris Burkov
2022-03-15 0:00 ` Eric Biggers
2022-02-15 0:09 ` [PATCH v6 3/4] btrfs: test verity orphans with dmlogwrites Boris Burkov
2022-02-15 0:09 ` [PATCH v6 4/4] generic: test fs-verity EFBIG scenarios Boris Burkov
2022-03-15 2:16 ` Eric Biggers
2022-03-15 22:06 ` Boris Burkov [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=YjEN6AzzisfT9j7u@zen \
--to=boris@bur.io \
--cc=ebiggers@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.