public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
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

      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