From: Eric Biggers <ebiggers@kernel.org>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-fscrypt@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v2 03/11] fscrypt: split and rename setup_per_mode_enc_key()
Date: Mon, 10 Apr 2023 20:29:35 -0700 [thread overview]
Message-ID: <20230411032935.GC47625@sol.localdomain> (raw)
In-Reply-To: <4f2bbef32f245f3c6b7e75f68c90faa1c3c096f1.1681155143.git.sweettea-kernel@dorminy.me>
On Mon, Apr 10, 2023 at 03:39:56PM -0400, Sweet Tea Dorminy wrote:
> @@ -231,14 +221,39 @@ static int setup_per_mode_enc_key(struct fscrypt_info *ci,
> memzero_explicit(mode_key, mode->keysize);
> if (err)
> goto out_unlock;
> -done_unlock:
> - ci->ci_enc_key = *prep_key;
> - err = 0;
> +
> out_unlock:
The 'if (err)' block above is no longer needed.
> +static int find_mode_prepared_key(struct fscrypt_info *ci,
> + struct fscrypt_master_key *mk,
> + struct fscrypt_prepared_key *keys,
> + u8 hkdf_context, bool include_fs_uuid)
> +{
> + struct fscrypt_mode *mode = ci->ci_mode;
> + const u8 mode_num = mode - fscrypt_modes;
> + struct fscrypt_prepared_key *prep_key;
> + int err;
> +
> + if (WARN_ON_ONCE(mode_num > FSCRYPT_MODE_MAX))
> + return -EINVAL;
> +
> + prep_key = &keys[mode_num];
> + if (fscrypt_is_key_prepared(prep_key, ci)) {
> + ci->ci_enc_key = *prep_key;
> + return 0;
> + }
> + err = setup_new_mode_prepared_key(mk, prep_key, ci, hkdf_context,
> + include_fs_uuid);
> + if (err)
> + return err;
> +
> + ci->ci_enc_key = *prep_key;
> + return 0;
> +}
It actually should be find_or_create_mode_prepared_key(), right? It's confusing
to have a function that just says "find" actually create the thing it is looking
for.
But, with how long these function names would get, maybe we should just stick
with setup_mode_prepared_key()? Note that it has the same semantics (find or
create) as fscrypt_setup_ino_hash_key(), which this patchset doesn't change.
- Eric
next prev parent reply other threads:[~2023-04-11 3:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 19:39 [PATCH v2 00/11] fscrypt: rearrangements preliminary to extent encryption Sweet Tea Dorminy
2023-04-10 19:39 ` [PATCH v2 01/11] fscrypt: move inline crypt decision to info setup Sweet Tea Dorminy
2023-04-10 19:39 ` [PATCH v2 02/11] fscrypt: split and rename setup_file_encryption_key() Sweet Tea Dorminy
2023-04-11 3:24 ` Eric Biggers
2023-04-10 19:39 ` [PATCH v2 03/11] fscrypt: split and rename setup_per_mode_enc_key() Sweet Tea Dorminy
2023-04-11 3:29 ` Eric Biggers [this message]
2023-04-10 19:39 ` [PATCH v2 04/11] fscrypt: move dirhash key setup away from IO key setup Sweet Tea Dorminy
2023-04-11 3:35 ` Eric Biggers
2023-04-10 19:39 ` [PATCH v2 05/11] fscrypt: reduce special-casing of IV_INO_LBLK_32 Sweet Tea Dorminy
2023-04-11 3:38 ` Eric Biggers
2023-04-10 19:39 ` [PATCH v2 06/11] fscrypt: make infos have a pointer to prepared keys Sweet Tea Dorminy
2023-04-11 3:44 ` Eric Biggers
2023-04-11 16:26 ` Sweet Tea Dorminy
2023-04-10 19:40 ` [PATCH v2 07/11] fscrypt: move all the shared mode key setup deeper Sweet Tea Dorminy
2023-04-11 3:56 ` Eric Biggers
2023-04-10 19:40 ` [PATCH v2 08/11] fscrypt: make ci->ci_direct_key a bool not a pointer Sweet Tea Dorminy
2023-04-11 3:57 ` Eric Biggers
2023-04-10 19:40 ` [PATCH v2 09/11] fscrypt: make prepared keys record their type Sweet Tea Dorminy
2023-04-10 19:40 ` [PATCH v2 10/11] fscrypt: explicitly track prepared parts of key Sweet Tea Dorminy
2023-04-11 4:05 ` Eric Biggers
2023-04-11 16:45 ` Sweet Tea Dorminy
2023-04-11 21:21 ` Eric Biggers
2023-04-10 19:40 ` [PATCH v2 11/11] fscrypt: split key alloc and preparation Sweet Tea Dorminy
2023-04-11 3:18 ` [PATCH v2 00/11] fscrypt: rearrangements preliminary to extent encryption Eric Biggers
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=20230411032935.GC47625@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-fscrypt@vger.kernel.org \
--cc=sweettea-kernel@dorminy.me \
--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.