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@xxxxxxxxxx> 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.
|