[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4QzlGHWmSDFlqFc@gondor.apana.org.au>
Date: Mon, 28 Nov 2022 12:05:40 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [v2 PATCH 0/9] crypto: Add helpers for allocating with DMA
alignment
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,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists