David Sterba <dsterba@xxxxxxx> writes: > 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. OK, it then makes sense to use this filename instead. Thanks for clarifying, David. Cheers, -- Luís
|