linux-kernel - Re: [PATCH v6 0/8] btrfs: add fscrypt support, PART 1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251118150444.GW13846@twin.jikos.cz>
Date: Tue, 18 Nov 2025 16:04:44 +0100
From: David Sterba <dsterba@...e.cz>
To: Daniel Vacek <neelx@...e.com>
Cc: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
	David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 0/8] btrfs: add fscrypt support, PART 1

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.