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:
 * v8 - Clean my mistakenly added Signed-off-by:
 * v7 - Drop the checksum patch for now. It will make more sense later.
      - Drop the btrfs/330 fix. It seems no longer needed after the years.
 * v6 vs v5 [1] is 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 (4):
  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

Omar Sandoval (1):
  btrfs: disable various operations on encrypted inodes

Sweet Tea Dorminy (1):
  btrfs: disable verity on encrypted inodes

 fs/btrfs/backref.c   | 68 +++++++++++++++++++++-----------------------
 fs/btrfs/bio.c       | 10 +++++++
 fs/btrfs/bio.h       |  2 ++
 fs/btrfs/file-item.c |  2 +-
 fs/btrfs/inode.c     |  4 +++
 fs/btrfs/ioctl.c     | 27 +++---------------
 fs/btrfs/reflink.c   |  7 +++++
 fs/btrfs/verity.c    |  3 ++
 8 files changed, 63 insertions(+), 60 deletions(-)

-- 
2.51.0

On Tue, Nov 18, 2025 at 05:08:37PM +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:
>  * v8 - Clean my mistakenly added Signed-off-by:
>  * v7 - Drop the checksum patch for now. It will make more sense later.
>       - Drop the btrfs/330 fix. It seems no longer needed after the years.
>  * v6 vs v5 [1] is 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.

Thanks, I've added it to for-next with the following note:

    Note: The patch was taken from v5 of fscrypt patchset
    (https://lore.kernel.org/linux-btrfs/cover.1706116485.git.josef@toxicpanda.com/)
    which was handled over time by various people: Omar
    Sandoval, Sweet Tea Dorminy, Josef Bacik.

And added your signed-off as you're submitting it.

On Wed, 19 Nov 2025 at 13:16, David Sterba <dsterba@suse.cz> wrote:
> On Tue, Nov 18, 2025 at 05:08:37PM +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:
> >  * v8 - Clean my mistakenly added Signed-off-by:
> >  * v7 - Drop the checksum patch for now. It will make more sense later.
> >       - Drop the btrfs/330 fix. It seems no longer needed after the years.
> >  * v6 vs v5 [1] is 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.
>
> Thanks, I've added it to for-next with the following note:
>
>     Note: The patch was taken from v5 of fscrypt patchset
>     (https://lore.kernel.org/linux-btrfs/cover.1706116485.git.josef@toxicpanda.com/)
>     which was handled over time by various people: Omar
>     Sandoval, Sweet Tea Dorminy, Josef Bacik.
>
> And added your signed-off as you're submitting it.

Thanks. I'll do the same with the rest of the series.

Patches 1 to 3 just add dead code without the actual fscrypt support,
which you've not even posted anywhere never mind having queued it up.
Please don't add this kind of code without the user in the same series.

On Wed, Nov 19, 2025 at 12:23:35AM -0800, Christoph Hellwig wrote:
> Patches 1 to 3 just add dead code without the actual fscrypt support,
> which you've not even posted anywhere never mind having queued it up.
> Please don't add this kind of code without the user in the same series.

The fscrypt series is about 50 patches, last v5 iteration is at [1] and
I suggested to pick any independent patches we could ahead of time.

[1] https://lore.kernel.org/linux-btrfs/cover.1706116485.git.josef@toxicpanda.com/

On Wed, Nov 19, 2025 at 09:59:41AM +0100, David Sterba wrote:
> On Wed, Nov 19, 2025 at 12:23:35AM -0800, Christoph Hellwig wrote:
> > Patches 1 to 3 just add dead code without the actual fscrypt support,
> > which you've not even posted anywhere never mind having queued it up.
> > Please don't add this kind of code without the user in the same series.
> 
> The fscrypt series is about 50 patches, last v5 iteration is at [1] and
> I suggested to pick any independent patches we could ahead of time.

Getting any independent work in first is always a good idea.  Patches 4-6
fit that, but patches 1-3 are everything but.

On Wed, Nov 19, 2025 at 01:06:36AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 19, 2025 at 09:59:41AM +0100, David Sterba wrote:
> > On Wed, Nov 19, 2025 at 12:23:35AM -0800, Christoph Hellwig wrote:
> > > Patches 1 to 3 just add dead code without the actual fscrypt support,
> > > which you've not even posted anywhere never mind having queued it up.
> > > Please don't add this kind of code without the user in the same series.
> > 
> > The fscrypt series is about 50 patches, last v5 iteration is at [1] and
> > I suggested to pick any independent patches we could ahead of time.
> 
> Getting any independent work in first is always a good idea.  Patches 4-6
> fit that, but patches 1-3 are everything but.

We already have fscrypt preparations code that is not yet used, this is
not different.