This series cleans up and fixes the way that ext4 and f2fs handle the
test_dummy_encryption mount option:
- Patches 1-2 make test_dummy_encryption consistently require that the
'encrypt' feature flag already be enabled and that
CONFIG_FS_ENCRYPTION be enabled. Note, this will cause xfstest
ext4/053 to start failing; my xfstests patch "ext4/053: update the
test_dummy_encryption tests" will fix that.
- Patches 3-7 replace the fscrypt_set_test_dummy_encryption() helper
function with new functions that work properly with the new mount API,
by splitting up the parsing, checking, and applying steps. These fix
bugs that were introduced when ext4 started using the new mount API.
We can either take all these patches through the fscrypt tree, or we can
take them in multiple cycles as follows:
1. patch 1 via ext4, patch 2 via f2fs, patch 3-4 via fscrypt
2. patch 5 via ext4, patch 6 via f2fs
3. patch 7 via fscrypt
Ted and Jaegeuk, let me know what you prefer.
Changed v1 => v2:
- Added patches 2-7
- Also reject test_dummy_encryption when !CONFIG_FS_ENCRYPTION
Eric Biggers (7):
ext4: only allow test_dummy_encryption when supported
f2fs: reject test_dummy_encryption when !CONFIG_FS_ENCRYPTION
fscrypt: factor out fscrypt_policy_to_key_spec()
fscrypt: add new helper functions for test_dummy_encryption
ext4: fix up test_dummy_encryption handling for new mount API
f2fs: use the updated test_dummy_encryption helper functions
fscrypt: remove fscrypt_set_test_dummy_encryption()
fs/crypto/fscrypt_private.h | 6 +-
fs/crypto/keyring.c | 64 +++++++++++---
fs/crypto/keysetup.c | 20 +----
fs/crypto/policy.c | 121 +++++++++++++------------
fs/ext4/ext4.h | 6 --
fs/ext4/super.c | 172 ++++++++++++++++++++----------------
fs/f2fs/super.c | 28 ++++--
include/linux/fscrypt.h | 41 ++++++++-
8 files changed, 280 insertions(+), 178 deletions(-)
base-commit: 8013d1d3d2e33236dee13a133fba49ad55045e79
--
2.36.0
On Sat, Apr 30, 2022 at 10:08:50PM -0700, Eric Biggers wrote:
> This series cleans up and fixes the way that ext4 and f2fs handle the
> test_dummy_encryption mount option:
>
> - Patches 1-2 make test_dummy_encryption consistently require that the
> 'encrypt' feature flag already be enabled and that
> CONFIG_FS_ENCRYPTION be enabled. Note, this will cause xfstest
> ext4/053 to start failing; my xfstests patch "ext4/053: update the
> test_dummy_encryption tests" will fix that.
>
> - Patches 3-7 replace the fscrypt_set_test_dummy_encryption() helper
> function with new functions that work properly with the new mount API,
> by splitting up the parsing, checking, and applying steps. These fix
> bugs that were introduced when ext4 started using the new mount API.
>
> We can either take all these patches through the fscrypt tree, or we can
> take them in multiple cycles as follows:
>
> 1. patch 1 via ext4, patch 2 via f2fs, patch 3-4 via fscrypt
> 2. patch 5 via ext4, patch 6 via f2fs
> 3. patch 7 via fscrypt
>
> Ted and Jaegeuk, let me know what you prefer.
>
> Changed v1 => v2:
> - Added patches 2-7
> - Also reject test_dummy_encryption when !CONFIG_FS_ENCRYPTION
>
> Eric Biggers (7):
> ext4: only allow test_dummy_encryption when supported
> f2fs: reject test_dummy_encryption when !CONFIG_FS_ENCRYPTION
> fscrypt: factor out fscrypt_policy_to_key_spec()
> fscrypt: add new helper functions for test_dummy_encryption
> ext4: fix up test_dummy_encryption handling for new mount API
> f2fs: use the updated test_dummy_encryption helper functions
> fscrypt: remove fscrypt_set_test_dummy_encryption()
Since I haven't heard from anyone, I've gone ahead and applied patches 3-4 to
fscrypt#master for 5.19, so that the filesystem-specific patches can be taken in
5.20. But patches 1-2 could still be applied now.
Any feedback on this series would be greatly appreciated!
- Eric
On 05/09, Eric Biggers wrote:
> On Sat, Apr 30, 2022 at 10:08:50PM -0700, Eric Biggers wrote:
> > This series cleans up and fixes the way that ext4 and f2fs handle the
> > test_dummy_encryption mount option:
> >
> > - Patches 1-2 make test_dummy_encryption consistently require that the
> > 'encrypt' feature flag already be enabled and that
> > CONFIG_FS_ENCRYPTION be enabled. Note, this will cause xfstest
> > ext4/053 to start failing; my xfstests patch "ext4/053: update the
> > test_dummy_encryption tests" will fix that.
> >
> > - Patches 3-7 replace the fscrypt_set_test_dummy_encryption() helper
> > function with new functions that work properly with the new mount API,
> > by splitting up the parsing, checking, and applying steps. These fix
> > bugs that were introduced when ext4 started using the new mount API.
> >
> > We can either take all these patches through the fscrypt tree, or we can
> > take them in multiple cycles as follows:
> >
> > 1. patch 1 via ext4, patch 2 via f2fs, patch 3-4 via fscrypt
> > 2. patch 5 via ext4, patch 6 via f2fs
> > 3. patch 7 via fscrypt
> >
> > Ted and Jaegeuk, let me know what you prefer.
> >
> > Changed v1 => v2:
> > - Added patches 2-7
> > - Also reject test_dummy_encryption when !CONFIG_FS_ENCRYPTION
> >
> > Eric Biggers (7):
> > ext4: only allow test_dummy_encryption when supported
> > f2fs: reject test_dummy_encryption when !CONFIG_FS_ENCRYPTION
> > fscrypt: factor out fscrypt_policy_to_key_spec()
> > fscrypt: add new helper functions for test_dummy_encryption
> > ext4: fix up test_dummy_encryption handling for new mount API
> > f2fs: use the updated test_dummy_encryption helper functions
> > fscrypt: remove fscrypt_set_test_dummy_encryption()
>
> Since I haven't heard from anyone, I've gone ahead and applied patches 3-4 to
> fscrypt#master for 5.19, so that the filesystem-specific patches can be taken in
> 5.20. But patches 1-2 could still be applied now.
Hi Eric,
Let me apply #2 in the f2fs tree first.
You can put "Acked-by: Jaegeuk Kim <[email protected]>" in #6.
Thanks,
>
> Any feedback on this series would be greatly appreciated!
>
> - Eric
On Fri, May 13, 2022 at 03:36:05PM -0400, Theodore Ts'o wrote:
> On Sat, Apr 30, 2022 at 10:08:50PM -0700, Eric Biggers wrote:
> > We can either take all these patches through the fscrypt tree, or we can
> > take them in multiple cycles as follows:
> >
> > 1. patch 1 via ext4, patch 2 via f2fs, patch 3-4 via fscrypt
> > 2. patch 5 via ext4, patch 6 via f2fs
> > 3. patch 7 via fscrypt
> >
> > Ted and Jaegeuk, let me know what you prefer.
>
> In order to avoid patch conflicts with other patch series, what I'd
> prefer is to take them in multiple cycles. I can take patch #1 in my
> initial pull request to Linus, and then do a second pull request to
> Linus with patch #5 post -rc1 or -rc2 (depending on when patches #3
> and #4 hit Linus's tree).
>
> Does that sound good?
That basically sounds fine. I've just sent out v3 of this series, with the fix
for the memory leak in parse_apply_sb_mount_options() as its own patch. That
patch can be applied now too, so you can take patches 1-2 of the v3 series in
your initial pull request.
- Eric
On Sat, Apr 30, 2022 at 10:08:50PM -0700, Eric Biggers wrote:
> We can either take all these patches through the fscrypt tree, or we can
> take them in multiple cycles as follows:
>
> 1. patch 1 via ext4, patch 2 via f2fs, patch 3-4 via fscrypt
> 2. patch 5 via ext4, patch 6 via f2fs
> 3. patch 7 via fscrypt
>
> Ted and Jaegeuk, let me know what you prefer.
In order to avoid patch conflicts with other patch series, what I'd
prefer is to take them in multiple cycles. I can take patch #1 in my
initial pull request to Linus, and then do a second pull request to
Linus with patch #5 post -rc1 or -rc2 (depending on when patches #3
and #4 hit Linus's tree).
Does that sound good?
- Ted