Re: dropping the non-inline mode for fscrypt?

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Mar 02, 2026 at 03:27:18PM +0100, Christoph Hellwig wrote:
> After just having run into another issue with missing testing for one of
> the path, I'd like to ask if we should look into dropping the non-inline
> mode for block based fscrypt?

Yes, I think that's the way to go now.

I do think the default should continue to be to use the well-tested
CPU-based encryption code (just accessed via blk-crypto-fallback
instead).  Inline encryption hardware should continue to be opt-in via
the inlinecrypt mount option, rather than used unconditionally.  To
allow this, we'll need to add a field 'allow_hardware' or similar to
struct bio_crypt_ctx.  Should be fairly straightforward though.

> I did a few simple fio based benchmarks, and writes are a minimal amount
> fast for the inline mode, while the reverse is true for reads.
> 
> The big blocker seems to be this comment in fscrypt_select_encryption_impl:
> 
>         /*
>          * When a page contains multiple logically contiguous filesystem blocks,
>          * some filesystem code only calls fscrypt_mergeable_bio() for the first
>          * block in the page. This is fine for most of fscrypt's IV generation
>          * strategies, where contiguous blocks imply contiguous IVs. But it
>          * doesn't work with IV_INO_LBLK_32. For now, simply exclude
>          * IV_INO_LBLK_32 with blocksize != PAGE_SIZE from inline encryption.
>          */

I think it would be pretty safe to drop support for IV_INO_LBLK_32 with
blocksize != PAGE_SIZE entirely, given that that case already doesn't
work with inlinecrypt.  The whole point of IV_INO_LBLK_32 is to be able
to use eMMC inline encryption hardware that support only 32-bit IVs.

I should have put in this restriction from the beginning, but I don't
anyone will care if it's added now.

> from touching the file system callers lately, the only obvious place
> for this is fscrypt_zeroout_range_inline_crypt helper, or did I miss
> anything else?

ext4_mpage_readpages() for example seems to call it only once per folio.
It was cited in the original discussion that resulted in this code:
https://lore.kernel.org/linux-fscrypt/20200629182250.GD20492@sol.localdomain/

> Does anyone have a good xfstests setup for the IV_INO_LBLK_32 mode?

Unfortunately not.  generic/369 does use IV_INO_LBLK_32 and verifies
that data is being encrypted correctly, but it's very unlikely to
exercise the DUN wraparound case.

The test_dummy_encryption mount option could be extended to allow
something like "test_dummy_encryption=v2,iv_ino_lblk_32", to cause the
test_dummy_encryption policy to use IV_INO_LBLK_32.

- Eric