Re: [PATCH v7 03/43] fscrypt: add a __fscrypt_file_open helper
From: Eric Biggers
Date: Mon Jun 01 2026 - 22:39:58 EST
On Wed, May 13, 2026 at 10:52:37AM +0200, Daniel Vacek wrote:
> From: Josef Bacik <josef@xxxxxxxxxxxxxx>
>
> We have fscrypt_file_open() which is meant to be called on files being
> opened so that their key is loaded when we start reading data from them.
>
> However for btrfs send we are opening the inode directly without a filp,
> so we need a different helper to make sure we can load the fscrypt
> context for the inode before reading its contents.
>
> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> Signed-off-by: Daniel Vacek <neelx@xxxxxxxx>
> ---
>
> No changes in v7.
> v6 changes:
> * Adapted to fscrypt changes since the last two years.
> v5: https://lore.kernel.org/linux-btrfs/4a372419c3fe6ad425e1b124c342a054e9d6db23.1706116485.git.josef@xxxxxxxxxxxxxx/
> ---
> fs/crypto/hooks.c | 38 ++++++++++++++++++++++++++++++++------
> include/linux/fscrypt.h | 8 ++++++++
> 2 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/fs/crypto/hooks.c b/fs/crypto/hooks.c
> index a7a8a3f581a0..3142cf106bde 100644
> --- a/fs/crypto/hooks.c
> +++ b/fs/crypto/hooks.c
> @@ -9,6 +9,37 @@
>
> #include "fscrypt_private.h"
>
> +/**
> + * __fscrypt_file_open() - prepare for filesystem-internal access to a
> + * possibly-encrypted regular file
> + * @dir: the inode for the directory via which the file is being accessed
> + * @inode: the inode being "opened"
> + *
> + * This is like fscrypt_file_open(), but instead of taking the 'struct file'
> + * being opened it takes the parent directory explicitly. This is intended for
> + * use cases such as "send/receive" which involve the filesystem accessing file
> + * contents without setting up a 'struct file'.
> + *
> + * Return: 0 on success, -ENOKEY if the key is missing, or another -errno code
> + */
> +int __fscrypt_file_open(struct inode *dir, struct inode *inode)
> +{
> + int err;
> +
> + err = fscrypt_require_key(inode);
> + if (err)
> + return err;
> +
> + if (!fscrypt_has_permitted_context(dir, inode)) {
> + fscrypt_warn(inode,
> + "Inconsistent encryption context (parent directory: %llu)",
> + dir->i_ino);
> + return -EPERM;
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(__fscrypt_file_open);
> +
> /**
> * fscrypt_file_open() - prepare to open a possibly-encrypted regular file
> * @inode: the inode being opened
> @@ -60,12 +91,7 @@ int fscrypt_file_open(struct inode *inode, struct file *filp)
> rcu_read_unlock();
>
> dentry_parent = dget_parent(dentry);
> - if (!fscrypt_has_permitted_context(d_inode(dentry_parent), inode)) {
> - fscrypt_warn(inode,
> - "Inconsistent encryption context (parent directory: %llu)",
> - d_inode(dentry_parent)->i_ino);
> - err = -EPERM;
> - }
> + err = __fscrypt_file_open(d_inode(dentry_parent), inode);
> dput(dentry_parent);
> return err;
> }
This change makes fscrypt_file_open() execute an unnecessary extra
fscrypt_require_key(). Could we just leave fscrypt_file_open() as-is?
- Eric