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.
