On Tue, 2 Jun 2026 at 04:34, Eric Biggers <[email protected]> wrote: > On Wed, May 13, 2026 at 10:52:37AM +0200, Daniel Vacek wrote: > > From: Josef Bacik <[email protected]> > > > > 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 <[email protected]> > > Signed-off-by: Daniel Vacek <[email protected]> > > --- > > > > 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.jo...@toxicpanda.com/ > > --- > > 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?
Yes, I'm aware of that. Well, it's static inline and gated only for encrypted inodes. But yeah, I'll refactor it a bit further. --nX > - Eric
