Re: [PATCHv5 3/3] dm-crypt: allow unaligned bio_vecs for direct io

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Jul 09, 2026 at 09:15:19AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
> 
> 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 <kbusch@kernel.org>

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/20260707053503.209874-12-ebiggers@kernel.org/).
But segment lengths not a multiple of 16 bytes will always be
inefficient to process and really should be avoided.

- Eric