Hi all, in the past we had various discussions that doing the blk-crypto fallback below the block layer causes all kinds of problems due to very late splitting and communicating up features.
This series turns that call chain upside down by requiring the caller to call into blk-crypto using a new submit_bio wrapper instead so that only hardware encryption bios are passed through the block layer as such. While doings this I also noticed that the existing blk-crypto-fallback code does various unprotected memory allocations which this converts to mempools, or from loops of mempool allocations to the new safe batch mempool allocator. There might be future avenues for optimization by using high order folio allocations that match the file systems preferred folio size, but for that'd probably want a batch folio allocator first, in addition to deferring it to avoid scope creep. Diffstat: block/blk-core.c | 10 - block/blk-crypto-fallback.c | 437 ++++++++++++++++++++------------------------ block/blk-crypto-internal.h | 31 +-- block/blk-crypto.c | 65 ++---- fs/buffer.c | 3 fs/crypto/bio.c | 89 +++++--- fs/ext4/page-io.c | 3 fs/ext4/readpage.c | 9 fs/f2fs/data.c | 4 fs/f2fs/file.c | 3 fs/iomap/direct-io.c | 3 include/linux/blk-crypto.h | 16 + include/linux/mempool.h | 7 mm/mempool.c | 173 ++++++++++++----- 14 files changed, 464 insertions(+), 389 deletions(-)
