On Tue, 18 Nov 2025 at 16:04, David Sterba <dsterba@suse.cz> wrote:
> On Wed, Nov 12, 2025 at 08:36:00PM +0100, Daniel Vacek wrote:
> > This is a revive of former work [1] of Omar, Sweet Tea and Josef to bring
> > native encryption support to btrfs.
> >
> > It will come in more parts. The first part this time is splitting the simple
> > and isolated stuff out first to reduce the size of the final patchset.
> >
> > Changes since v5 [1] are mostly rebase to the latest for-next and cleaning
> > up the conflicts.
> >
> > The remaining part needs further cleanup and a bit of redesign and it will
> > follow later.
> >
> > [1] https://lore.kernel.org/linux-btrfs/cover.1706116485.git.josef@toxicpanda.com/
> >
> > Josef Bacik (6):
> > btrfs: add a bio argument to btrfs_csum_one_bio
> > btrfs: add orig_logical to btrfs_bio
> > btrfs: don't rewrite ret from inode_permission
> > btrfs: move inode_to_path higher in backref.c
> > btrfs: don't search back for dir inode item in INO_LOOKUP_USER
> > btrfs: set the appropriate free space settings in reconfigure
> >
> > Omar Sandoval (1):
> > btrfs: disable various operations on encrypted inodes
> >
> > Sweet Tea Dorminy (1):
> > btrfs: disable verity on encrypted inodes
>
> Please resend the series what is OK for merge right now, I'm counting
> two dropped patches. For the signed-off we might need to add an
> explanation why there are so many or only keep the first one as the
> patch author, the others usually mean only the pass through and not
> really doing any contribution. Eventually there could be Co-developed-by
> but this would need more investigation in the previous patch iterations.
> This can be done once the patches are in for-next.
I just did. The SoBs I just kept as they were in v5 from Josef so I
understand that's what it was agreed on before.
--nX