mbox series

[0/10] crypto: Driver conversions for DMA alignment

Message ID Y4nDL50nToBbi4DS@gondor.apana.org.au
Headers show
Series crypto: Driver conversions for DMA alignment | expand

Message

Herbert Xu Dec. 2, 2022, 9:19 a.m. UTC 
These are the rest of the driver conversions in order for arm64
to safely lower the kmalloc alignment below that required for DMA.

My criteria for inclusion are:

1) the driver can be built on arm64.
2) the driver may perform DMA on the context structure.

I have worked through all the drivers in crypto but if you think
I've missed something please let me know.

Thanks,

Comments

Herbert Xu Dec. 2, 2022, 9:53 a.m. UTC | #1 
On Fri, Dec 02, 2022 at 05:49:21PM +0800, liulongfang wrote:
. 
> Hi, Herbert:
> There are also skcipher_request_ctx and aead_request_ctx in the hisilicon/sec2 driver
> that need to be updated.

Please show me where they do DMA directly on the context structure.
I wasn't able to find such a place.

Thanks,
Christoph Hellwig Dec. 4, 2022, 9:32 a.m. UTC | #2 
On Fri, Dec 02, 2022 at 05:19:43PM +0800, Herbert Xu wrote:
> These are the rest of the driver conversions in order for arm64
> to safely lower the kmalloc alignment below that required for DMA.

Btw, drivers/crypto/ has a lot of weird and most likely uses of
GFP_DMA.  Can someone look into those while we're doing DMA audits
of the cryto drivers?
Herbert Xu Dec. 6, 2022, 4:13 a.m. UTC | #3 
On Sun, Dec 04, 2022 at 01:32:08AM -0800, Christoph Hellwig wrote:
> On Fri, Dec 02, 2022 at 05:19:43PM +0800, Herbert Xu wrote:
> > These are the rest of the driver conversions in order for arm64
> > to safely lower the kmalloc alignment below that required for DMA.
> 
> Btw, drivers/crypto/ has a lot of weird and most likely uses of
> GFP_DMA.  Can someone look into those while we're doing DMA audits
> of the cryto drivers?

Yes they're clearly bogus.  Basically they are saying they want
memory that is aligned sufficiently for DMA.  So if Catalin's
patch-set will break this assumption, then all the GFP_DMA allocations
in drivers/crypto will need to be enlarged to take this into
account.

Cheers,
Christoph Hellwig Dec. 6, 2022, 6:27 a.m. UTC | #4 
On Tue, Dec 06, 2022 at 12:13:52PM +0800, Herbert Xu wrote:
> Yes they're clearly bogus.  Basically they are saying they want
> memory that is aligned sufficiently for DMA.  So if Catalin's
> patch-set will break this assumption, then all the GFP_DMA allocations
> in drivers/crypto will need to be enlarged to take this into
> account.

But GFP_DMA never did do anything at all about alignment.  It picks
allocations from ZONE_DMA (which on x86 is the first 16MB only).
Herbert Xu Dec. 6, 2022, 8:34 a.m. UTC | #5 
On Mon, Dec 05, 2022 at 10:27:58PM -0800, Christoph Hellwig wrote:
.
> But GFP_DMA never did do anything at all about alignment.  It picks
> allocations from ZONE_DMA (which on x86 is the first 16MB only).

Right.  I'm not arguing that they are correct or anything.  I'm
just saying that they are currently working on arm64 because of
the large minimum kmalloc alignment, and they will all be broken
afterwards.

Cheers,