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.
next prev parent 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