On Fri, 2021-12-10 at 11:46 -0800, Eric Biggers wrote: > On Thu, Dec 09, 2021 at 10:36:16AM -0500, Jeff Layton wrote: > > ceph_atomic_open needs to be able to call this. > > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > > --- > > fs/crypto/fscrypt_private.h | 26 -------------------------- > > fs/crypto/keysetup.c | 27 +++++++++++++++++++++++++++ > > include/linux/fscrypt.h | 5 +++++ > > 3 files changed, 32 insertions(+), 26 deletions(-) > > What is the use case for this, more precisely? I've been trying to keep > filesystems using helper functions like fscrypt_prepare_*() and > fscrypt_file_open() rather than setting up encryption keys directly, which is a > bit too low-level to be doing outside of fs/crypto/. > > Perhaps fscrypt_file_open() is what you're looking for here? That doesn't really help because we don't have the inode for the file yet at the point where we need the key. atomic_open basically does a lookup+open. You give it a directory inode and a dentry, and it issues an open request by filename. If it gets back ENOENT then we know that the thing is a negative dentry. In the lookup path, I used __fscrypt_prepare_readdir. This situation is a bit similar so I might be able to use that instead. OTOH, that doesn't fail when you don't have the key, and if you don't, there's not a lot of point in going any further here. -- Jeff Layton <jlayton@xxxxxxxxxx>
