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 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.