From: Eric Biggers <ebiggers@kernel.org>
To: Daniel Vacek <neelx@suse.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>, Jens Axboe <axboe@kernel.dk>,
David Sterba <dsterba@suse.com>,
linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Omar Sandoval <osandov@osandov.com>,
Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: Re: [PATCH v7 11/43] btrfs: add inode encryption contexts
Date: Mon, 1 Jun 2026 20:25:34 -0700 [thread overview]
Message-ID: <20260602032534.GH2295@sol> (raw)
In-Reply-To: <20260513085340.3673127-12-neelx@suse.com>
On Wed, May 13, 2026 at 10:52:45AM +0200, Daniel Vacek wrote:
> From: Omar Sandoval <osandov@osandov.com>
>
> fscrypt stores a context item with encrypted inodes that contains the
> related encryption information. fscrypt provides an arbitrary blob for
> the filesystem to store, and it does not clearly fit into an existing
> structure, so this goes in a new item type.
>
> Signed-off-by: Omar Sandoval <osandov@osandov.com>
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Daniel Vacek <neelx@suse.com>
> ---
>
> v7 changes:
> * Fix a path leak as found by Chri's AI review.
> v6 changes:
> * Shorten the inode context key macro name to BTRFS_FSCRYPT_INODE_CTX_KEY.
> v5: https://lore.kernel.org/linux-btrfs/5a88efb484b0874a7430b83bc6e5f6b9aa5858d5.1706116485.git.josef@toxicpanda.com/
> ---
> fs/btrfs/fscrypt.c | 116 ++++++++++++++++++++++++++++++++
> fs/btrfs/fscrypt.h | 2 +
> fs/btrfs/inode.c | 19 ++++++
> fs/btrfs/ioctl.c | 8 ++-
> include/uapi/linux/btrfs_tree.h | 10 +++
> 5 files changed, 153 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/fscrypt.c b/fs/btrfs/fscrypt.c
> index 6cfba7d94e72..c503f817cbe7 100644
> --- a/fs/btrfs/fscrypt.c
> +++ b/fs/btrfs/fscrypt.c
> @@ -1,10 +1,126 @@
> // SPDX-License-Identifier: GPL-2.0
>
> +#include <linux/iversion.h>
> #include "ctree.h"
> +#include "accessors.h"
> #include "btrfs_inode.h"
> +#include "disk-io.h"
> +#include "fs.h"
> #include "fscrypt.h"
> +#include "ioctl.h"
> +#include "messages.h"
> +#include "transaction.h"
> +#include "xattr.h"
> +
> +static int btrfs_fscrypt_get_context(struct inode *inode, void *ctx, size_t len)
> +{
> + struct btrfs_key key = {
> + .objectid = btrfs_ino(BTRFS_I(inode)),
> + .type = BTRFS_FSCRYPT_INODE_CTX_KEY,
> + .offset = 0,
> + };
> + struct btrfs_path *path;
> + struct extent_buffer *leaf;
> + unsigned long ptr;
> + int ret;
> +
> +
> + path = btrfs_alloc_path();
> + if (!path)
> + return -ENOMEM;
> +
> + ret = btrfs_search_slot(NULL, BTRFS_I(inode)->root, &key, path, 0, 0);
> + if (ret) {
> + len = -ENOENT;
> + goto out;
> + }
> +
> + leaf = path->nodes[0];
> + ptr = btrfs_item_ptr_offset(leaf, path->slots[0]);
> + /* fscrypt provides max context length, but it could be less */
> + len = min_t(size_t, len, btrfs_item_size(leaf, path->slots[0]));
> + read_extent_buffer(leaf, ctx, ptr, len);
> +
> +out:
> + btrfs_free_path(path);
> + return len;
> +}
This doesn't conform to the calling convention for
fscrypt_operations::get_context, specifically in the cases where
-ENODATA and -ERANGE are expected.
/*
* Get the fscrypt context of the given inode.
*
* @inode: the inode whose context to get
* @ctx: the buffer into which to get the context
* @len: length of the @ctx buffer in bytes
*
* Return: On success, returns the length of the context in bytes; this
* may be less than @len. On failure, returns -ENODATA if the
* inode doesn't have a context, -ERANGE if the context is
* longer than @len, or another -errno code.
*/
int (*get_context)(struct inode *inode, void *ctx, size_t len);
It also seems to be assuming that any error from btrfs_search_slot()
means "not found", which isn't correct.
The size_t variable called 'len' is also being used to store negative
errno values, which is weird.
> +static int btrfs_fscrypt_set_context(struct inode *inode, const void *ctx,
> + size_t len, void *fs_data)
> +{
> + struct btrfs_trans_handle *trans = fs_data;
> + struct btrfs_key key = {
> + .objectid = btrfs_ino(BTRFS_I(inode)),
> + .type = BTRFS_FSCRYPT_INODE_CTX_KEY,
> + .offset = 0,
> + };
> + struct btrfs_path *path = NULL;
> + struct extent_buffer *leaf;
> + unsigned long ptr;
> + int ret;
> +
> + if (!trans)
> + trans = btrfs_start_transaction(BTRFS_I(inode)->root, 2);
> + if (IS_ERR(trans))
> + return PTR_ERR(trans);
> +
> + path = btrfs_alloc_path();
> + if (!path) {
> + ret = -ENOMEM;
> + goto out_err;
> + }
> +
> + ret = btrfs_search_slot(trans, BTRFS_I(inode)->root, &key, path, 0, 1);
> + if (ret < 0)
> + goto out_err;
> +
> + if (ret > 0) {
> + btrfs_release_path(path);
> + ret = btrfs_insert_empty_item(trans, BTRFS_I(inode)->root, path, &key, len);
> + if (ret)
> + goto out_err;
> + }
> +
> + leaf = path->nodes[0];
> + ptr = btrfs_item_ptr_offset(leaf, path->slots[0]);
> +
> + len = min_t(size_t, len, btrfs_item_size(leaf, path->slots[0]));
> + write_extent_buffer(leaf, ctx, ptr, len);
> + btrfs_mark_buffer_dirty(trans, leaf);
> + btrfs_release_path(path);
> +
> + if (fs_data)
> + goto out_err;
> +
> + BTRFS_I(inode)->flags |= BTRFS_INODE_ENCRYPT;
> + btrfs_sync_inode_flags_to_i_flags(BTRFS_I(inode));
> + inode_inc_iversion(inode);
> + inode_set_ctime_current(inode);
> + ret = btrfs_update_inode(trans, BTRFS_I(inode));
> + if (ret)
> + goto out_abort;
> + btrfs_free_path(path);
> + btrfs_end_transaction(trans);
> + return 0;
> +out_abort:
> + btrfs_abort_transaction(trans, ret);
> +out_err:
> + if (!fs_data)
> + btrfs_end_transaction(trans);
> + btrfs_free_path(path);
> + return ret;
> +}
The 'len = min_t(size_t, len, btrfs_item_size(leaf, path->slots[0]));'
line seems scary, since it just truncates the data given.
> @@ -199,7 +203,7 @@ static int check_fsflags(unsigned int old_flags, unsigned int flags)
> FS_NOATIME_FL | FS_NODUMP_FL | \
> FS_SYNC_FL | FS_DIRSYNC_FL | \
> FS_NOCOMP_FL | FS_COMPR_FL |
> - FS_NOCOW_FL))
> + FS_NOCOW_FL | FS_ENCRYPT_FL))
> return -EOPNOTSUPP;
Do you know why FS_VERITY_FL isn't in this mask?
- Eric
next prev parent reply other threads:[~2026-06-02 3:26 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 8:52 [PATCH v7 00/43] btrfs: add fscrypt support Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 01/43] fscrypt: add per-extent encryption support Daniel Vacek
2026-06-01 22:44 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 02/43] fscrypt: allow inline encryption for extent based encryption Daniel Vacek
2026-06-01 22:49 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 03/43] fscrypt: add a __fscrypt_file_open helper Daniel Vacek
2026-06-02 2:33 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 04/43] fscrypt: conditionally don't wipe mk secret until the last active user is done Daniel Vacek
2026-06-01 23:04 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 05/43] blk-crypto: add a process bio callback Daniel Vacek
2026-06-01 23:09 ` Eric Biggers
2026-06-02 2:48 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 06/43] fscrypt: add a process_bio hook to fscrypt_operations Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 07/43] fscrypt: expose fscrypt_nokey_name Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 08/43] fscrypt: add documentation about extent encryption Daniel Vacek
2026-06-01 23:43 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 09/43] btrfs: add infrastructure for safe em freeing Daniel Vacek
2026-06-02 2:54 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 10/43] btrfs: start using fscrypt hooks Daniel Vacek
2026-06-02 3:12 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 11/43] btrfs: add inode encryption contexts Daniel Vacek
2026-06-02 3:25 ` Eric Biggers [this message]
2026-05-13 8:52 ` [PATCH v7 12/43] btrfs: add new FEATURE_INCOMPAT_ENCRYPT flag Daniel Vacek
2026-06-02 3:27 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 13/43] btrfs: adapt readdir for encrypted and nokey names Daniel Vacek
2026-06-01 23:44 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 14/43] btrfs: handle " Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 15/43] btrfs: implement fscrypt ioctls Daniel Vacek
2026-06-02 2:35 ` Eric Biggers
2026-05-13 8:52 ` [PATCH v7 16/43] btrfs: select encryption dependencies if FS_ENCRYPTION Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 17/43] btrfs: add get_devices hook for fscrypt Daniel Vacek
2026-05-22 9:19 ` Christoph Hellwig
2026-05-22 12:00 ` Daniel Vacek
2026-05-22 12:17 ` Christoph Hellwig
2026-05-29 14:51 ` Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 18/43] btrfs: set file extent encryption excplicitly Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 19/43] btrfs: add fscrypt_info and encryption_type to extent_map Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 20/43] btrfs: add fscrypt_info and encryption_type to ordered_extent Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 21/43] btrfs: plumb through setting the fscrypt_info for ordered extents Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 22/43] btrfs: populate the ordered_extent with the fscrypt context Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 23/43] btrfs: keep track of fscrypt info and orig_start for dio reads Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 24/43] btrfs: add extent encryption context tree item type Daniel Vacek
2026-05-13 8:52 ` [PATCH v7 25/43] btrfs: pass through fscrypt_extent_info to the file extent helpers Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 26/43] btrfs: implement the fscrypt extent encryption hooks Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 27/43] btrfs: setup fscrypt_extent_info for new extents Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 28/43] btrfs: populate ordered_extent with the orig offset Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 29/43] btrfs: set the bio fscrypt context when applicable Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 30/43] btrfs: add a bio argument to btrfs_csum_one_bio Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 31/43] btrfs: limit encrypted writes to 256 segments Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 32/43] btrfs: implement process_bio cb for fscrypt Daniel Vacek
2026-05-22 9:19 ` Christoph Hellwig
2026-05-29 15:43 ` Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 33/43] btrfs: implement read repair for encryption Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 34/43] btrfs: add test_dummy_encryption support Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 35/43] btrfs: make btrfs_ref_to_path handle encrypted filenames Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 36/43] btrfs: deal with encrypted symlinks in send Daniel Vacek
2026-06-02 2:42 ` Eric Biggers
2026-05-13 8:53 ` [PATCH v7 37/43] btrfs: decrypt file names for send Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 38/43] btrfs: load the inode context before sending writes Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 39/43] btrfs: set the appropriate free space settings in reconfigure Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 40/43] btrfs: support encryption with log replay Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 41/43] btrfs: disable auto defrag on encrypted files Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 42/43] btrfs: disable encryption on RAID5/6 Daniel Vacek
2026-05-13 8:53 ` [PATCH v7 43/43] btrfs: disable send if we have encryption enabled Daniel Vacek
2026-05-22 7:00 ` [PATCH v7 00/43] btrfs: add fscrypt support Daniel Vacek
2026-05-31 0:28 ` Eric Biggers
2026-06-01 18:57 ` David Sterba
2026-06-01 20:09 ` Eric Biggers
2026-06-02 2:25 ` Eric Biggers
2026-06-02 4:19 ` 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=20260602032534.GH2295@sol \
--to=ebiggers@kernel.org \
--cc=axboe@kernel.dk \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=jaegeuk@kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neelx@suse.com \
--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 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.