All of lore.kernel.org
 help / color / mirror / Atom feed
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 08/11] fscrypt: make ci->ci_direct_key a bool not a pointer
Date: Mon, 10 Apr 2023 20:57:10 -0700	[thread overview]
Message-ID: <20230411035710.GH47625@sol.localdomain> (raw)
In-Reply-To: <ae5cc986b52b950ee81d613093310a52be3972d9.1681155143.git.sweettea-kernel@dorminy.me>

On Mon, Apr 10, 2023 at 03:40:01PM -0400, Sweet Tea Dorminy wrote:
> The ci_direct_key field is only used for v1 direct key policies,
> recording the direct key that needs to have its refcount reduced when
> the crypt_info is freed. However, now that crypt_info->ci_enc_key is a
> pointer to the authoritative prepared key -- embedded in the direct key,
> in this case, we no longer need to keep a full pointer to the direct key
> -- we can use container_of() to go from the prepared key to its
> surrounding direct key. Thus we can make ci_direct_key a bool instead of
> a pointer, saving a few bytes.
> 
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
>  fs/crypto/fscrypt_private.h | 7 +++----
>  fs/crypto/keysetup.c        | 2 +-
>  fs/crypto/keysetup_v1.c     | 7 +++++--
>  3 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index 5011737b60b3..b575fb58a506 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -234,10 +234,9 @@ struct fscrypt_info {
>  	struct list_head ci_master_key_link;
>  
>  	/*
> -	 * If non-NULL, then encryption is done using the master key directly
> -	 * and ci_enc_key will equal ci_direct_key->dk_key.
> +	 * If true, then encryption is done using the master key directly.
>  	 */
> -	struct fscrypt_direct_key *ci_direct_key;
> +	bool ci_direct_key;

This just gets deleted by the next patch.  Should they be folded together?

- Eric

  reply	other threads:[~2023-04-11  3:57 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
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 [this message]
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=20230411035710.GH47625@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.