Re: [PATCH v2 04/17] btrfs: start using fscrypt hooks

[David Sterba <dsterba@suse.cz>]

On Mon, Jul 17, 2023 at 04:34:17PM +0100, Luís Henriques wrote:
> (Sorry for the send.  Somehow, my MUA is failing to set the CC header.)
> Sweet Tea Dorminy <sweettea-kernel@dorminy.me> writes:
> > --- a/fs/btrfs/file.c
> > +++ b/fs/btrfs/file.c
> > @@ -3698,6 +3698,9 @@ static int btrfs_file_open(struct inode *inode, struct file *filp)
> >  
> >  	filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC | FMODE_BUF_WASYNC |
> >  		        FMODE_CAN_ODIRECT;
> > +	ret = fscrypt_file_open(inode, filp);
> > +	if (ret)
> > +		return ret;
> >  
> >  	ret = fsverity_file_open(inode, filp);
> >  	if (ret)
> > diff --git a/fs/btrfs/fscrypt.c b/fs/btrfs/fscrypt.c
> 
> Nit: both ext4 and ubifs (and in a (hopefully!) near future, ceph) use
> 'crypto.c' for naming this file.  I'd prefer consistency, but meh.

I'm still not decied if we should all crypto as plain crypto or
distinguish the backends, where fscrypt is one of them and a proposed
one by a different name. The difference is the depth of the subvolume
support, fscrypt is on the level of files and directories, the subvolume
level and snapshots can be grouped in another way.