On Tue, Jul 22, 2025 at 01:02:25PM -0700, Eric Biggers wrote:
> On Tue, Jul 22, 2025 at 09:27:19PM +0200, Christian Brauner wrote:
> > Store the offset of the fscrypt data pointer from struct inode in struct
> > super_operations. Both are embedded in the filesystem's private inode.
> >
> > This will allow us to drop the fscrypt data pointer from struct inode
> > itself and move it into the filesystem's inode.
> >
> > Signed-off-by: Christian Brauner <brau...@kernel.org>
> > ---
> > include/linux/fs.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 96c7925a6551..991089969e71 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -2332,6 +2332,7 @@ enum freeze_holder {
> > };
> >
> > struct super_operations {
> > + ptrdiff_t i_fscrypt;
> > struct inode *(*alloc_inode)(struct super_block *sb);
> > void (*destroy_inode)(struct inode *);
> > void (*free_inode)(struct inode *);
>
> If using inode_operations was ruled out, so we have to go through the
> super_block to get to an operations struct anyway, wouldn't it make more
> sense to use fscrypt_operations and fsverity_operations? They are
Good idea.
> accessible as inode->i_sb->s_cop and inode->i_sb->s_vop. Same number of
> dereferences as getting to inode->i_sb->s_op.
I also like Al's idea to move the offset directly into struct
super_block.
Hm, but conceptually moving it into the respective operations would make
a lot more sense...
I'll just sketch both and see what feels cleaner.
