On Mon, Aug 11, 2025 at 09:39:07AM -0700, Eric Biggers wrote: > On Mon, Aug 11, 2025 at 03:34:35PM +0200, Christian Brauner wrote: > > On Mon, Aug 11, 2025 at 03:17:01PM +0200, Christian Brauner wrote: > > > 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-c8e11488a...@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-c8e11488a...@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! > > > > I just pulled the series and now I see that you also changed the > > authorship of every single patch in the series from me to you and put my > > Co-developed-by in there. > > > > I mean I acknowledge that there's changes between the branches and > > there's some function renaming but it's not to the point where > > authorship should be changed. And if you think that's necessary than it > > would be something you would want to talk to me about first. > > > > I don't care about the stats but it was always hugely frustrating to me > > when I started kernel development when senior kernel developers waltzed > > in and thought they'd just take things over so I try very hard to not do > > that unless this is agreed upon first. > > If you want to keep the authorship that's fine with me. Make sure > you've checked the diff: the diff between v4 and v5 is larger than the > diff between the base and either version. And as I mentioned, I rewrote > the commit messages and divided some of the changes into commits > differently as well. If the situation was flipped, I wouldn't want to > be kept as the author. But I realize there are different opinions about > this sort of thing, and I'm totally fine with whatever you prefer.
It's not that I oppose it per se it's just that it would be nice to have gotten a heads-up about both the rewrite and the authorship change. (Sorry, still on vacation and so answers are delayed.)
