Re: [PATCH v5 00/13] Move fscrypt and fsverity info out of struct inode

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Aug 10, 2025 at 10:47:32AM +0200, Christian Brauner wrote:
> On Sun, Aug 10, 2025 at 12:56:53AM -0700, Eric Biggers wrote:
> > This is a cleaned-up implementation of moving the i_crypt_info and
> > i_verity_info pointers out of 'struct inode' and into the fs-specific
> > part of the inode, as proposed previously by Christian at
> > https://lore.kernel.org/r/20250723-work-inode-fscrypt-v4-0-c8e11488a0e6@kernel.org/
> > 
> > The high-level concept is still the same: fs/crypto/ and fs/verity/
> > locate the pointer by adding an offset to the address of struct inode.
> > The offset is retrieved from fscrypt_operations or fsverity_operations.
> > 
> > I've cleaned up a lot of the details, including:
> > - Grouped changes into patches differently
> > - Rewrote commit messages and comments to be clearer
> > - Adjusted code formatting to be consistent with existing code
> > - Removed unneeded #ifdefs
> > - Improved choice and location of VFS_WARN_ON_ONCE() statements
> > - Added missing kerneldoc for ubifs_inode::i_crypt_info
> > - Moved field initialization to init_once functions when they exist
> > - Improved ceph offset calculation and removed unneeded static_asserts
> > - fsverity_get_info() now checks IS_VERITY() instead of v_ops
> > - fscrypt_put_encryption_info() no longer checks IS_ENCRYPTED(), since I
> >   no longer think it's actually correct there.
> > - verity_data_blocks() now keeps doing a raw dereference
> > - Dropped fscrypt_set_inode_info() 
> > - Renamed some functions
> > - Do offset calculation using int, so we don't rely on unsigned overflow
> > - And more.
> > 
> > For v4 and earlier, see
> > https://lore.kernel.org/r/20250723-work-inode-fscrypt-v4-0-c8e11488a0e6@kernel.org/
> > 
> > I'd like to take this series through the fscrypt tree for 6.18.
> > (fsverity normally has a separate tree, but by choosing just one tree
> > for this, we'll avoid conflicts in some places.)
> 
> Woh woh. First, I had a cleaned up version ready for v6.18 so if you
> plan on taking over someone's series and resend then maybe ask the
> author first whether that's ok or not. I haven't seen you do that. You
> just caused duplicated work for no reason.

Ah, sorry about that.  When I started looking at it again yesterday
there turned out to be way too many cleanups and fixes I wanted to make
(beyond the comments I gave earlier), and I hadn't seen activity from
you on it in a while.  So I figured it would be easier to just send a
series myself.  But I should have asked you first, sorry.

> And second general infrastructure changes that touch multiple fses and
> generic fs infrastructure I very much want to go through VFS trees.
> We'll simply use a shared tree.

So you'd like to discontinue the fscrypt and fsverity trees?  That's
what they are for: general infrastructure shared by multiple
filesystems.  Or is this comment just for this series in particular,
presumably because it touches 'struct inode'?

- Eric