Hi Sweet Tea, On Mon, Apr 10, 2023 at 03:39:53PM -0400, Sweet Tea Dorminy wrote: > As per [1], extent-based encryption needs to split allocating and > preparing crypto_skciphers, since extent infos will be loaded at IO time > and crypto_skciphers cannot be allocated at IO time. > > This changeset undertakes to split the existing code to clearly > distinguish preparation and allocation of fscrypt_prepared_keys, > wrapping crypto_skciphers. Elegance of code is in the eye of the > beholder, but I've tried a decent variety of arrangements here and this > seems like the clearest result to me; happy to adjust as desired, and > more changesets coming soon, this just seemed like the clearest cutoff > point for preliminaries without being pure refactoring. > > Patchset should apply cleanly to fscrypt/for-next (as per base-commit > below), and pass ext4/f2fs tests (kvm-xfstests is not currently > succesfully setting up ubifs volumes for me). > > [1] https://lore.kernel.org/linux-btrfs/Y7NQ1CvPyJiGRe00@sol.localdomain/ > > Changes from v1: > Included change 1, erroneously dropped, and generated patches using --base. > > Sweet Tea Dorminy (11): > fscrypt: move inline crypt decision to info setup. > fscrypt: split and rename setup_file_encryption_key() > fscrypt: split and rename setup_per_mode_enc_key() > fscrypt: move dirhash key setup away from IO key setup > fscrypt: reduce special-casing of IV_INO_LBLK_32 > fscrypt: make infos have a pointer to prepared keys > fscrypt: move all the shared mode key setup deeper > fscrypt: make ci->ci_direct_key a bool not a pointer > fscrypt: make prepared keys record their type. > fscrypt: explicitly track prepared parts of key > fscrypt: split key alloc and preparation > > fs/crypto/crypto.c | 2 +- > fs/crypto/fname.c | 4 +- > fs/crypto/fscrypt_private.h | 73 +++++-- > fs/crypto/inline_crypt.c | 30 +-- > fs/crypto/keysetup.c | 387 ++++++++++++++++++++++++------------ > fs/crypto/keysetup_v1.c | 13 +- > 6 files changed, 340 insertions(+), 169 deletions(-) > Thanks for the patchset! I don't see any major issues with these cleanups; I'll leave some comments on individual patches. But, I also feel that most of them aren't too convincing on their own. So, I'm very interested in seeing where you go with this. It seems that your goal is to allow filesystems to more directly create and manage fscrypt_prepared_key structs. Do you know when you'll have a proof of concept ready that includes the changes/additions to the interface between fs/crypto/ and filesystems (include/linux/fscrypt.h)? - Eric
|