From: Eric Biggers <ebiggers@kernel.org>
To: Boris Burkov <boris@bur.io>
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 02:16:30 +0000 [thread overview]
Message-ID: <Yi/2/isOZMX3Riww@gmail.com> (raw)
In-Reply-To: <f8189930d20888a7ac95b7fc2fbb0d522e8851fc.1644883592.git.boris@bur.io>
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.
- Eric
next prev parent reply other threads:[~2022-03-15 2:16 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 [this message]
2022-03-15 22:06 ` Boris Burkov
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=Yi/2/isOZMX3Riww@gmail.com \
--to=ebiggers@kernel.org \
--cc=boris@bur.io \
--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.