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: Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
	"Theodore Y . Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	kernel-team@meta.com, linux-btrfs@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH v3 08/17] btrfs: handle nokey names.
Date: Wed, 9 Aug 2023 16:32:21 -0400	[thread overview]
Message-ID: <20230809203221.GC2561679@perftesting> (raw)
In-Reply-To: <adfd6682729107364481959f2ee4850c276ce211.1691510179.git.sweettea-kernel@dorminy.me>

On Tue, Aug 08, 2023 at 01:12:10PM -0400, Sweet Tea Dorminy wrote:
> For encrypted or unencrypted names, we calculate the offset for the dir
> item by hashing the name for the dir item. However, this doesn't work
> for a long nokey name, where we do not have the complete ciphertext.
> Instead, fscrypt stores the filesystem-provided hash in the nokey name,
> and we can extract it from the fscrypt_name structure in such a case.
> 
> Additionally, for nokey names, if we find the nokey name on disk we can
> update the fscrypt_name with the disk name, so add that to searching for
> diritems.
> 
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
>  fs/btrfs/dir-item.c | 37 +++++++++++++++++++++++++++++++++++--
>  fs/btrfs/fscrypt.c  | 27 +++++++++++++++++++++++++++
>  fs/btrfs/fscrypt.h  | 11 +++++++++++
>  3 files changed, 73 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/dir-item.c b/fs/btrfs/dir-item.c
> index da95ae411d72..ee7dad888f53 100644
> --- a/fs/btrfs/dir-item.c
> +++ b/fs/btrfs/dir-item.c
> @@ -231,6 +231,28 @@ struct btrfs_dir_item *btrfs_lookup_dir_item(struct btrfs_trans_handle *trans,
>  	return di;
>  }
>  
> +/*
> + * If appropriate, populate the disk name for a fscrypt_name looked up without
> + * a key.
> + *
> + * @path:	The path to the extent buffer in which the name was found.
> + * @di:		The dir item corresponding.
> + * @fname:	The fscrypt_name to perhaps populate.
> + *
> + * Returns: 0 if the name is already populated or the dir item doesn't exist
> + * or the name was successfully populated, else an error code.
> + */
> +static int ensure_disk_name_from_dir_item(struct btrfs_path *path,
> +					  struct btrfs_dir_item *di,
> +					  struct fscrypt_name *name)
> +{
> +	if (name->disk_name.name || !di)
> +		return 0;
> +
> +	return btrfs_fscrypt_get_disk_name(path->nodes[0], di,
> +					   &name->disk_name);
> +}
> +
>  /*
>   * Lookup for a directory item by fscrypt_name.
>   *
> @@ -257,8 +279,12 @@ struct btrfs_dir_item *btrfs_lookup_dir_item_fname(struct btrfs_trans_handle *tr
>  
>  	key.objectid = dir;
>  	key.type = BTRFS_DIR_ITEM_KEY;
> -	key.offset = btrfs_name_hash(name->disk_name.name, name->disk_name.len);
> -	/* XXX get the right hash for no-key names */
> +
> +	if (!name->disk_name.name)
> +		key.offset = name->hash | ((u64)name->minor_hash << 32);
> +	else
> +		key.offset = btrfs_name_hash(name->disk_name.name,
> +					     name->disk_name.len);
>  
>  	ret = btrfs_search_slot(trans, root, &key, path, mod, -mod);
>  	if (ret == 0)
> @@ -266,6 +292,8 @@ struct btrfs_dir_item *btrfs_lookup_dir_item_fname(struct btrfs_trans_handle *tr
>  
>  	if (ret == -ENOENT || (di && IS_ERR(di) && PTR_ERR(di) == -ENOENT))
>  		return NULL;
> +	if (ret == 0)
> +		ret = ensure_disk_name_from_dir_item(path, di, name);
>  	if (ret < 0)
>  		di = ERR_PTR(ret);
>  
> @@ -382,7 +410,12 @@ btrfs_search_dir_index_item(struct btrfs_root *root, struct btrfs_path *path,
>  	btrfs_for_each_slot(root, &key, &key, path, ret) {
>  		if (key.objectid != dirid || key.type != BTRFS_DIR_INDEX_KEY)
>  			break;
> +
>  		di = btrfs_match_dir_item_fname(root->fs_info, path, name);
> +		if (di)
> +			ret = ensure_disk_name_from_dir_item(path, di, name);
> +		if (ret)
> +			break;

This is a little wonky, I'd rather just

if (!di)
	continue;
ret = ensure_disk_name_from_dir_item(path, di, name);
if (ret)
	break
return di;

Thanks,

Josef

  reply	other threads:[~2023-08-09 20:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08 17:12 [PATCH v3 00/17] btrfs: add encryption feature Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 01/17] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 02/17] btrfs: disable verity " Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 03/17] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 04/17] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 05/17] btrfs: add inode encryption contexts Sweet Tea Dorminy
2023-08-09 20:20   ` Josef Bacik
2023-08-08 17:12 ` [PATCH v3 06/17] btrfs: add new FEATURE_INCOMPAT_ENCRYPT flag Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 07/17] btrfs: adapt readdir for encrypted and nokey names Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 08/17] btrfs: handle " Sweet Tea Dorminy
2023-08-09 20:32   ` Josef Bacik [this message]
2023-08-08 17:12 ` [PATCH v3 09/17] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 10/17] btrfs: add encryption to CONFIG_BTRFS_DEBUG Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 11/17] btrfs: add get_devices hook for fscrypt Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 12/17] btrfs: turn on inlinecrypt mount option for encrypt Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 13/17] btrfs: turn on the encryption ioctls Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 14/17] btrfs: create and free extent fscrypt_infos Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 15/17] btrfs: start tracking extent encryption context info Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 16/17] btrfs: explicitly track file extent length and encryption Sweet Tea Dorminy
2023-08-08 17:12 ` [PATCH v3 17/17] btrfs: save and load fscrypt extent contexts Sweet Tea Dorminy
2023-08-09 20:38   ` Josef Bacik
2023-08-09 20:39 ` [PATCH v3 00/17] btrfs: add encryption feature Josef Bacik

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=20230809203221.GC2561679@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.