On Fri, Jul 10, 2026 at 10:14:19PM -0600, Keith Busch wrote: > On Fri, Jul 10, 2026 at 08:54:40PM -0400, Eric Biggers wrote: > > > > 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'm not the one introducing ENOMEM consideration here.
You are. This patch starts allowing misaligned segments, which trigger the use of bounce buffers in the crypto code as I explained. Currently, dm-crypt relies on its alignment requirement to avoid those cases. > Indeed, patch 2 in this series addresses this very thing ahead of what > I'm asking for. I don't think patch 2 is sufficient, as BLK_STS_RESOURCE is often not going to get handled correctly. > > I think you'll need to take the limitations of crypto_skcipher into > > account. See the comment above CRYPTO_ALG_ALLOCATES_MEMORY. > > The block layer's queue limits is the single source of truth for what > the backing device at any layer can accept. If you've some constraints > that are not appropriately described there, then let's fix that. I agree that dm-crypt's queue limits should accurately describe its constraints. This patch makes it no longer do so. - Eric
