On 7/15/25 15:21, Christoph Hellwig wrote: > 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. Hmmm. Device mapper does not call bio_split_to_limits() in general. Exception is for zoned devices (patches queued up in block-next). But it should be trivial to add such call for all IOs if blk-crypto is enabled on the dm-device. -- Damien Le Moal Western Digital Research
