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/[email protected]/ > 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
