On Fri, Jan 09, 2026 at 07:07:40AM +0100, Christoph Hellwig wrote: > 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.
Reviewed-by: Eric Biggers <[email protected]> > Jens and Eric: I guess despite the fscrypt patches, the block tree > would probably be the best fit. Or do we need a separate branch? Please go ahead and take these through the block tree. Thanks! - Eric
