mbox series

[v2,0/9] crypto: Add helpers for allocating with DMA alignment

Message ID Y4BGC2BPesy3qsEm@gondor.apana.org.au
Headers
Series crypto: Add helpers for allocating with DMA alignment |

Message

Herbert Xu Nov. 25, 2022, 4:35 a.m. UTC 
  This patch series adds helpers to allow drivers to explicitly
request ARCH_DMA_MINALIGN when allocating memory through the
Crypto API.

Note that I've only converted one file in one driver as this
is only meant to show how it's done and find out what else we
may need.

Other drivers will be added later.

Thanks,

Comments

Ard Biesheuvel Nov. 25, 2022, 12:17 p.m. UTC | #1 
On Fri, 25 Nov 2022 at 05:35, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> This patch series adds helpers to allow drivers to explicitly
> request ARCH_DMA_MINALIGN when allocating memory through the
> Crypto API.
>
> Note that I've only converted one file in one driver as this
> is only meant to show how it's done and find out what else we
> may need.
>
> Other drivers will be added later.
>

Hi Herbert,

This approach seems conceptually similar to what I proposed a while ago:
https://lore.kernel.org/all/20220406142715.2270256-1-ardb@kernel.org/

If we agree that creating a distinction between ordinary allocations
and ones that are rounded up to DMA alignment is ok, I wonder if we
could minimize the churn by simply choosing between one or the other
by taking the CRYPTO_ALG_ASYNC flag into account. On x86 and other
arches that don't care about the distinction, none of this has any
effect anyway. And on arm64, only hardware implementations use the
CRYPTO_ALG_ASYNC flag, which makes its presence a reasonable heuristic
to decide whether an algo implementation is backed by hardware that
relies on DMA (the penalty for getting it wrong would be to use DMA
ailgnment unnecessarily, which we already do today anyway)

We'd still need changes in the generic crypto layer to distinguish the
two cases, but we wouldn't need any changes to the drivers, which
seems like a huge benefit to me
Herbert Xu Nov. 28, 2022, 4:05 a.m. UTC | #2 
On Fri, Nov 25, 2022 at 01:17:55PM +0100, Ard Biesheuvel wrote:
>
> We'd still need changes in the generic crypto layer to distinguish the
> two cases, but we wouldn't need any changes to the drivers, which
> seems like a huge benefit to me

I think we should go through the drivers anyway.  Because it isn't
just allocations from the Crypto API that'll bite us.

When I'm working through the drivers, I'm actually looking at what
they're mapping for DMA and where it's coming from.  Only when the
driver stores DMA-mapped data in the ctx structures am I changing
the drivers to add the extra padding.

Some of the drviers are doing small allocations for things like the
IV or keys with the GFP_DMA flag and hoping that it gives the correct
alignment.

Cheers,