Re: dropping the non-inline mode for fscrypt?

[Christoph Hellwig <hch@lst.de>]

On Mon, Mar 02, 2026 at 01:22:36PM -0800, Eric Biggers wrote:
> 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.

Sounds fine.  Given that you're more familiar with this can I sign
up you to do it?  Otherwise I can add it to my todo list, but chances
are that I'll get some of the subtle interactions wrong.

> 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.

That sounds even better.