On Thu, Jul 09, 2026 at 09:15:19AM -0700, Keith Busch wrote: > From: Keith Busch <[email protected]> > > Many storage devices can handle DMA for data that is not aligned to the > logical block size. The block and filesystem layers have introduced > updates to allow that kind of memory alignment flexibility when > possible. > > dm-crypt, however, currently constrains itself to aligned memory because > it sends a single scatterlist element for the in/out list to the encrypt > and decrypt algorithms. This forces applications that have unaligned > data to copy through a bounce buffer, increasing CPU and memory > utilization. > > Use multiple scatterlist elements as needed to relax the memory > alignment requirement. To keep this simple, this more flexible > constraint is enabled only for certain encryption and initialization > vector types, specifically the ones that don't have additional use for > the request scatterlist elements beyond pointing to user data. > > In the unlikely case where the incoming bio uses a highly fragmented > vector, the four inline scatterlist elements may not be enough, so > allocate a temporary scatterlist when needed, falling back to a mempool > for the in and out buffers to guarantee forward progress if the initial > allocation fails. > > Signed-off-by: Keith Busch <[email protected]>
So what is the minimum SG entry length alignment this can result in? Once that get misaligned enough, crypto_skcipher_encrypt() and crypto_skcipher_decrypt() start allocating bounce buffers internally. That code has no mempool fallback and can fail with ENOMEM. I think you'll need to take the limitations of crypto_skcipher into account. See the comment above CRYPTO_ALG_ALLOCATES_MEMORY. Note: I'm working on fixing at least AES-XTS to not allocate memory (https://lore.kernel.org/linux-crypto/[email protected]/). But segment lengths not a multiple of 16 bytes will always be inefficient to process and really should be avoided. - Eric
