From: Eric Biggers <ebiggers@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/556: add a check to make sure ext4 supports encrypted casefolding
Date: Thu, 21 Apr 2022 11:01:49 -0700 [thread overview]
Message-ID: <YmGcDdLRlfSwUxmZ@sol.localdomain> (raw)
In-Reply-To: <YNDOdrW0cEOhC9rZ@gmail.com>
On Mon, Jun 21, 2021 at 10:37:58AM -0700, Eric Biggers wrote:
> On Mon, Jun 21, 2021 at 12:49:01PM -0400, Theodore Ts'o wrote:
> > diff --git a/tests/generic/556 b/tests/generic/556
> > index 3145188c..7916a08e 100755
> > --- a/tests/generic/556
> > +++ b/tests/generic/556
> > @@ -16,6 +16,7 @@ status=1 # failure is thea default
> > . ./common/attr
> >
> > _supported_fs generic
> > +_require_encrypted_casefold
>
> This isn't an encrypt+casefold test though, but rather just a casefold test. It
> only becomes an encrypt+casefold test when $MOUNT_OPTIONS includes
> test_dummy_encryption.
>
> I think we shouldn't update the test itself, but rather make
> _require_scratch_casefold() call _require_encrypted_casefold() if
> test_dummy_encryption is in $MOUNT_OPTIONS.
>
Hi Ted, just to follow up on this patch which never got merged:
I tried to reproduce the test failure with the 5.4 and 5.10 kernels, whose ext4
supported casefold but not encrypt+casefold. However, it does *not* reproduce
with the "ext4/encrypt" configuration of kvm-xfstests, since
_require_scratch_casefold() already detects that the filesystem cannot mounted
with both the encrypt and casefold features:
if ! _try_scratch_mount &>>seqres.full; then
_notrun "kernel can't mount filesystem with the encoding set by userspace"
fi
I think the problem is that you were running xfstests with test_dummy_encryption
but without adding "-O encrypt" to EXT_MKFS_OPTIONS. That sort of works because
of the following code in __ext4_fill_super() in the kernel which force-enables
the encrypt feature if the test_dummy_encryption mount option was given:
if (DUMMY_ENCRYPTION_ENABLED(sbi) && !sb_rdonly(sb) &&
!ext4_has_feature_encrypt(sb)) {
ext4_set_feature_encrypt(sb);
ext4_commit_super(sb);
}
However, I don't think ext4 should be doing this. The kernel should generally
not be messing with the feature flags, and this code can force-enable 'encrypt'
in cases where e2fsprogs would *not* allow it (e.g. the encrypt+casefold
situation being encountered here). Also, f2fs doesn't allow this.
So I am planning to send a kernel patch to remove the above code from ext4.
- Eric
prev parent reply other threads:[~2022-04-21 18:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-21 16:49 [PATCH] generic/556: add a check to make sure ext4 supports encrypted casefolding Theodore Ts'o
2021-06-21 17:00 ` Darrick J. Wong
2021-06-21 17:37 ` Eric Biggers
2022-04-21 18:01 ` 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=YmGcDdLRlfSwUxmZ@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=tytso@mit.edu \
/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