Message-ID: <20250811-distribuieren-nilpferd-bef047fa7992@brauner>
Date: Mon, 11 Aug 2025 15:17:01 +0200
From: Christian Brauner <brauner@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-fscrypt@...r.kernel.org, fsverity@...ts.linux.dev, 
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, 
	linux-f2fs-devel@...ts.sourceforge.net, linux-mtd@...ts.infradead.org, linux-btrfs@...r.kernel.org, 
	ceph-devel@...r.kernel.org
Subject: Re: [PATCH v5 00/13] Move fscrypt and fsverity info out of struct
 inode

On Sun, Aug 10, 2025 at 02:03:02AM -0700, Eric Biggers wrote:
> 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.

So I started working on this pretty much right away. And I had planned
on sending it out rather soon but then thought to better wait for -rc1
to be released because I saw you had a bunch of crypto changes in for
-rc1 that would've caused merge conflicts. It's no big deal overall but
I just don't like that I wasted massaging all that stuff. So next time a
heads-up would be nice. Thank you!

> 
> > 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'?

My comment just applies this series. I'm not here to take away your
trees ofc unless you would like to have them go through the VFS batch.
That's something that some people like Amir have started doing.

I'll put the series into vfs-6.17.inode and push it out then you can
base any additional changes on top of that. I'll not touch it unless you
tell me to. Linus knows that VFS trees often have work that is used as
the base for other trees so he will merge VFS trees before any of the
smaller trees and I always mention this to him.

Powered by blists - more mailing lists