Re: [PATCH v2 2/2] block: Rework splitting of encrypted bios

[Christoph Hellwig <hch@lst.de>]

On Mon, Jul 14, 2025 at 11:11:17PM -0700, Eric Biggers wrote:
> I've actually been thinking of going in the other direction: dropping
> the support for fs-layer file contents encryption from ext4 and f2fs,
> and instead just relying on blk-crypto.  That would simplify ext4 and
> f2fs quite a bit, as they'd then have just one file contents encryption
> code path to support.  Also, blk-crypto "just works" with large folios,
> whereas the fs-layer code doesn't support large folios yet.
> 
> But that will only work if blk-crypto-fallback continues to support all
> block devices.
> 
> So, effectively you are advocating for keeping the fs-layer file
> contents encryption code in ext4 and f2fs forever?

I think those two concerns are almost unrelated.

Dropping the fscrypt code and relying on blk-crypto is a good idea and
should be done.

But at the same time we should stop pretend that the block layer will
handle the fallback, and instead require drivers to explicitly support
blk-crypto either natively or the fallback, and else fscrypt or other
blk-crypto users simply aren't supported at all.

Note that with something like this series from Bart all drivers that call
bio_split_to_limits will just support blk-crypto, and that includes all
blk-mq drivers and device mapper.  So without further work you'll just be
left with a few random drivers that almost no one cares about left
uncovered.  If someone wants to run fscrypt on those they can wire it up
to manually call into the blk-crypto fallback, which should not be hard.