public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
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>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
	kernel-team@fb.com, Omar Sandoval <osandov@osandov.com>
Subject: Re: [PATCH v2 13/20] btrfs: add fscrypt_context items.
Date: Wed, 7 Sep 2022 22:43:24 +0200	[thread overview]
Message-ID: <20220907204324.GL32411@twin.jikos.cz> (raw)
In-Reply-To: <827a00815cb4a9a91ff3977d71f40ff765728f04.1662420176.git.sweettea-kernel@dorminy.me>

On Mon, Sep 05, 2022 at 08:35:28PM -0400, Sweet Tea Dorminy wrote:
> +static int btrfs_fscrypt_get_context(struct inode *inode, void *ctx, size_t len)
> +{
> +	struct btrfs_root *root = BTRFS_I(inode)->root;
> +	struct inode *put_inode = NULL;
> +	struct btrfs_key key;
> +	struct btrfs_path *path;
> +	struct extent_buffer *leaf;
> +	unsigned long ptr;
> +	int ret;
> +
> +	if (btrfs_root_flags(&root->root_item) & BTRFS_ROOT_SUBVOL_FSCRYPT) {
> +		inode = btrfs_iget(inode->i_sb, BTRFS_FIRST_FREE_OBJECTID,
> +				   root);
> +		if (IS_ERR(inode))
> +			return PTR_ERR(inode);
> +		put_inode = inode;
> +	}
> +
> +	path = btrfs_alloc_path();
> +	if (!path)
> +		return -ENOMEM;
> +
> +	key = (struct btrfs_key) {
> +		.objectid = btrfs_ino(BTRFS_I(inode)),
> +		.type = BTRFS_FSCRYPT_CTXT_ITEM_KEY,
> +		.offset = 0,
> +	};

Please use the following for key initialization.

	key.objectid = ...;
	key.type = ...;
	key.offset = ...;

> +static int btrfs_fscrypt_set_context(struct inode *inode, const void *ctx,
> +				     size_t len, void *fs_data)
> +{
> +	struct btrfs_root *root = BTRFS_I(inode)->root;
> +	struct btrfs_trans_handle *trans;
> +	int is_subvolume = inode->i_ino == BTRFS_FIRST_FREE_OBJECTID;
> +	int ret;
> +	struct btrfs_path *path;
> +	struct btrfs_key key = {
> +		.objectid = btrfs_ino(BTRFS_I(inode)),
> +		.type = BTRFS_FSCRYPT_CTXT_ITEM_KEY,
> +		.offset = 0,
> +	};

This kind of initialization in the declaration block is ok, possibly
with only the simple initializers like btrfs_ino or normal constants.

> +	if (btrfs_root_flags(&root->root_item) & BTRFS_ROOT_SUBVOL_FSCRYPT) {
> +		bool same_policy;
> +		struct inode *root_inode = NULL;

Newlines between declrataions and statements

> +		root_inode = btrfs_iget(inode->i_sb, BTRFS_FIRST_FREE_OBJECTID,
> +				   root);
> +		if (IS_ERR(inode))
> +			return PTR_ERR(inode);
> +		same_policy = fscrypt_have_same_policy(inode, root_inode);
> +		iput(root_inode);
> +		if (same_policy)
> +			return 0;
> +	}
> +
> +	if (fs_data) {
> +		/*
> +		 * We are setting the context as part of an existing
> +		 * transaction. This happens when we are inheriting the context
> +		 * for a new inode.
> +		 */
> +		trans = fs_data;
> +	} else {
> +		/*
> +		 * 1 for the inode item
> +		 * 1 for the fscrypt item
> +		 * 1 for the root item if the inode is a subvolume
> +		 */
> +		trans = btrfs_start_transaction(root, 2 + is_subvolume);
> +		if (IS_ERR(trans))
> +			return PTR_ERR(trans);
> +	}
> +
> +	path = btrfs_alloc_path();
> +	if (!path)
> +		return -ENOMEM;
> +	ret = btrfs_search_slot(trans, BTRFS_I(inode)->root, &key, path, 0, 1);
> +	if (ret == 0) {
> +		struct extent_buffer *leaf = path->nodes[0];
> +		unsigned long ptr = btrfs_item_ptr_offset(leaf, path->slots[0]);

Newlines between declrataions and statements, you'll find the rest

> +		len = min_t(size_t, len, btrfs_item_size(leaf, path->slots[0]));
> +		write_extent_buffer(leaf, ctx, ptr, len);
> +		btrfs_mark_buffer_dirty(leaf);
> +		btrfs_free_path(path);
> +		goto out;
> +	} else if (ret < 0) {
> +		goto out;
> +	}
> +	btrfs_free_path(path);
> +
> +	ret = btrfs_insert_item(trans, BTRFS_I(inode)->root, &key, (void *) ctx, len);
> +	if (ret)
> +		goto out;
> +
> +	BTRFS_I(inode)->flags |= BTRFS_INODE_FSCRYPT_CONTEXT;
> +	btrfs_sync_inode_flags_to_i_flags(inode);
> +	inode_inc_iversion(inode);
> +	inode->i_ctime = current_time(inode);
> +	ret = btrfs_update_inode(trans, root, BTRFS_I(inode));
> +	if (ret)
> +		goto out;
> +
> +	/*
> +	 * For new subvolumes, the root item is already initialized with
> +	 * the BTRFS_ROOT_SUBVOL_FSCRYPT flag.
> +	 */
> +	if (!fs_data && is_subvolume) {
> +		u64 root_flags = btrfs_root_flags(&root->root_item);
> +
> +		btrfs_set_root_flags(&root->root_item,
> +				     root_flags |
> +				     BTRFS_ROOT_SUBVOL_FSCRYPT);
> +		ret = btrfs_update_root(trans, root->fs_info->tree_root,
> +					&root->root_key,
> +					&root->root_item);
> +	}
> +out:
> +	if (fs_data)
> +		return ret;
> +
> +	if (ret)
> +		btrfs_abort_transaction(trans, ret);
> +	else
> +		btrfs_end_transaction(trans);
> +	return ret;
> +}
> +
> +	if (args->encrypt)
> +		(*trans_num_items)++; /* 1 to add fscrypt item */

Please put the comment on a separate line, like it's on the lines below.

>  	if (args->orphan) {
>  		/* 1 to add orphan item */
>  		(*trans_num_items)++;
> @@ -787,6 +788,13 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir,
>  		return -ETXTBSY;
>  	}
>  
> +	if ((btrfs_root_flags(&root->root_item) & BTRFS_ROOT_SUBVOL_FSCRYPT) &&
> +	    !IS_ENCRYPTED(dir)) {
> +		btrfs_warn(fs_info,
> +			   "cannot snapshot encrypted volume to unencrypted destination");

Do we want to print that to the log? There are several EXDEV causes,
only another one prints a message and I think it should not.

> +		return -EXDEV;
> +	}
> +
>  	pending_snapshot = kzalloc(sizeof(*pending_snapshot), GFP_KERNEL);
>  	if (!pending_snapshot)
>  		return -ENOMEM;
> --- a/include/uapi/linux/btrfs_tree.h
> +++ b/include/uapi/linux/btrfs_tree.h
> @@ -144,6 +144,8 @@
>  #define BTRFS_VERITY_DESC_ITEM_KEY	36
>  #define BTRFS_VERITY_MERKLE_ITEM_KEY	37
>  
> +#define BTRFS_FSCRYPT_CTXT_ITEM_KEY	41

The context is per inode, so OK the key is needed and the number is
leaving enough space in case we'd need to add more.

  reply	other threads:[~2022-09-07 20:48 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06  0:35 [PATCH v2 00/20] btrfs: add fscrypt integration Sweet Tea Dorminy
2022-09-06  0:35 ` [PATCH v2 01/20] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2022-09-08 13:41   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 02/20] fscrypt: add flag allowing partially-encrypted directories Sweet Tea Dorminy
2022-09-08 13:43   ` Josef Bacik
2022-09-12  1:42   ` Eric Biggers
2022-09-15 18:58     ` Sweet Tea Dorminy
2022-09-13 10:07   ` Anand Jain
2022-09-13 11:02     ` Neal Gompa
2022-09-06  0:35 ` [PATCH v2 03/20] fscrypt: add fscrypt_have_same_policy() to check inode compatibility Sweet Tea Dorminy
2022-09-08 13:53   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 04/20] fscrypt: allow fscrypt_generate_iv() to distinguish filenames Sweet Tea Dorminy
2022-09-08 14:01   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 05/20] fscrypt: add extent-based encryption Sweet Tea Dorminy
2022-09-07 19:59   ` Omar Sandoval
2022-09-08 15:33   ` Josef Bacik
2022-09-10 18:53   ` kernel test robot
2022-09-12  1:34   ` Eric Biggers
2022-09-06  0:35 ` [PATCH v2 06/20] fscrypt: document btrfs' fscrypt quirks Sweet Tea Dorminy
2022-09-08 15:34   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 07/20] btrfs: store directory's encryption state Sweet Tea Dorminy
2022-09-08 15:37   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 08/20] btrfs: use fscrypt_names instead of name/len everywhere Sweet Tea Dorminy
2022-09-07 20:04   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 09/20] btrfs: setup fscrypt_names from dentrys using helper Sweet Tea Dorminy
2022-09-08 19:11   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method Sweet Tea Dorminy
2022-09-08 19:27   ` Josef Bacik
2022-09-09 10:15   ` David Sterba
2022-09-09 13:00     ` Christoph Hellwig
2022-09-09 13:34       ` David Sterba
2022-09-16 22:18         ` J Lovejoy
2022-09-19  2:00           ` Bradley M. Kuhn
2022-09-19 17:20             ` David Sterba
2022-09-19 16:52           ` David Sterba
2022-09-09 13:41       ` Chris Mason
2022-09-06  0:35 ` [PATCH v2 11/20] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2022-09-06  6:36   ` kernel test robot
2022-09-07 20:11   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 12/20] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2022-09-07 20:17   ` David Sterba
2022-09-07 20:42     ` Sweet Tea Dorminy
2022-09-12  1:50       ` Eric Biggers
2022-09-08 19:42   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 13/20] btrfs: add fscrypt_context items Sweet Tea Dorminy
2022-09-07 20:43   ` David Sterba [this message]
2022-09-08 20:06   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 14/20] btrfs: translate btrfs encryption flags and encrypted inode flag Sweet Tea Dorminy
2022-09-08 20:07   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 15/20] btrfs: store a fscrypt extent context per normal file extent Sweet Tea Dorminy
2022-09-07 21:10   ` David Sterba
2022-09-07 21:39     ` Sweet Tea Dorminy
2022-09-09 10:04       ` David Sterba
2022-09-06  0:35 ` [PATCH v2 16/20] btrfs: Add new FEATURE_INCOMPAT_FSCRYPT feature flag Sweet Tea Dorminy
2022-09-09 11:35   ` David Sterba
2022-09-12  1:36   ` Eric Biggers
2022-09-06  0:35 ` [PATCH v2 17/20] btrfs: reuse encrypted filename hash when possible Sweet Tea Dorminy
2022-09-07 21:24   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 18/20] btrfs: adapt directory read and lookup to potentially encrypted filenames Sweet Tea Dorminy
2022-09-08 20:15   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 19/20] btrfs: encrypt normal file extent data if appropriate Sweet Tea Dorminy
2022-09-08 20:19   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 20/20] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2022-09-07 21:33   ` David Sterba
2022-09-06 22:35 ` [PATCH v2 00/20] btrfs: add fscrypt integration Eric Biggers
2022-09-06 23:01   ` Sweet Tea Dorminy
2022-09-06 23:10     ` Eric Biggers
2022-09-07  0:01       ` Sweet Tea Dorminy
2022-09-07 19:38 ` David Sterba

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=20220907204324.GL32411@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=osandov@osandov.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox