All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	Eric Biggers <ebiggers@kernel.org>, Chris Mason <clm@fb.com>,
	David Sterba <dsterba@suse.com>,
	linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH v2 05/14] fscrypt: setup leaf inodes for extent encryption
Date: Fri, 14 Jul 2023 14:16:11 -0400	[thread overview]
Message-ID: <20230714181611.GB510453@perftesting> (raw)
In-Reply-To: <9a4890026719e5d6dc16ee9338f309f3fa452d16.1688927487.git.sweettea-kernel@dorminy.me>

On Sun, Jul 09, 2023 at 02:53:38PM -0400, Sweet Tea Dorminy wrote:
> For extent-based encryption, leaf/regular file inodes are special: it's
> useful to set their i_crypt_info field so that it's easy to inherit
> their encryption policy for a new extent, but they never need to do any
> encyption themselves. Additionally, since encryption can only be set up
> on a directory, not a single file, their encryption policy can always
> duplicate their parent inode's policy.
> 
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
>  fs/crypto/fscrypt_private.h | 17 +++++++++++++
>  fs/crypto/keysetup.c        | 49 ++++++++++++++++++++++++++-----------
>  2 files changed, 52 insertions(+), 14 deletions(-)
> 
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index c04454c289fd..260635e8b558 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -308,6 +308,23 @@ fscrypt_get_lblk_info(const struct inode *inode, u64 lblk, u64 *offset,
>  	return inode->i_crypt_info;
>  }
>  
> +/**
> + * fscrypt_uses_extent_encryption() -- whether an inode uses per-extent
> + *				       encryption
> + *
> + * @inode: the inode in question
> + *
> + * Return: true if the inode uses per-extent fscrypt_infos, false otherwise
> + */
> +static inline bool fscrypt_uses_extent_encryption(const struct inode *inode)
> +{
> +	// Non-regular files don't have extents
> +	if (!S_ISREG(inode->i_mode))
> +		return false;
> +
> +	// No filesystems currently use per-extent infos
> +	return false;

Wrong comment format.

> +}
>  
>  /* crypto.c */
>  extern struct kmem_cache *fscrypt_info_cachep;
> diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
> index c5f68cf65a6f..7469b2d8ac87 100644
> --- a/fs/crypto/keysetup.c
> +++ b/fs/crypto/keysetup.c
> @@ -747,27 +747,48 @@ fscrypt_setup_encryption_info(struct inode *inode,
>  int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported)
>  {
>  	int res;
> -	union fscrypt_context ctx;
> +	union fscrypt_context ctx = { 0 };
>  	union fscrypt_policy policy;
>  
>  	if (fscrypt_has_encryption_key(inode))
>  		return 0;
>  
> -	res = inode->i_sb->s_cop->get_context(inode, &ctx, sizeof(ctx));
> -	if (res < 0) {
> -		if (res == -ERANGE && allow_unsupported)
> -			return 0;
> -		fscrypt_warn(inode, "Error %d getting encryption context", res);
> -		return res;
> -	}
> +	if (fscrypt_uses_extent_encryption(inode)) {
> +		/*
> +		 * Nothing will be encrypted with this info, so we can borrow
> +		 * the parent (dir) inode's policy and use a zero nonce.
> +		 */
> +		struct dentry *dentry = d_find_any_alias(inode);
> +		struct dentry *parent_dentry = dget_parent(dentry);
> +		struct inode *dir = parent_dentry->d_inode;
> +		bool found = false;
>  

Can this be extracted to a helper to keep this function cleaner?  Thanks,

Josef

  reply	other threads:[~2023-07-14 18:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-09 18:53 [PATCH v2 00/14] fscrypt: add extent encryption Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 01/14] fscrypt: factor helper for locking master key Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 02/14] fscrypt: factor getting info for a specific block Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 03/14] fscrypt: adjust effective lblks based on extents Sweet Tea Dorminy
2023-07-14 18:13   ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 04/14] fscrypt: add a super_block pointer to fscrypt_info Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 05/14] fscrypt: setup leaf inodes for extent encryption Sweet Tea Dorminy
2023-07-14 18:16   ` Josef Bacik [this message]
2023-07-09 18:53 ` [PATCH v2 06/14] fscrypt: allow infos to be owned by extents Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 07/14] fscrypt: notify per-extent infos if master key vanishes Sweet Tea Dorminy
2023-07-17 14:54   ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 08/14] fscrypt: use an optional ino equivalent for per-extent infos Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 09/14] fscrypt: move function call warning of busy inodes Sweet Tea Dorminy
2023-07-17 14:59   ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 10/14] fscrypt: revamp key removal for extent encryption Sweet Tea Dorminy
2023-07-17 15:18   ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 11/14] fscrypt: add creation/usage/freeing of per-extent infos Sweet Tea Dorminy
2023-07-17 15:21   ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 12/14] fscrypt: allow load/save of extent contexts Sweet Tea Dorminy
2023-07-17 15:23   ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 13/14] fscrypt: save session key credentials for extent infos Sweet Tea Dorminy
2023-07-17 14:31   ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 14/14] fscrypt: update documentation for per-extent keys Sweet Tea Dorminy

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=20230714181611.GB510453@perftesting \
    --to=josef@toxicpanda.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-btrfs@vger.kernel.org \
    --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.