Message ID | Y4nDL50nToBbi4DS@gondor.apana.org.au (mailing list archive) |
---|---|
Headers | show |
Series | crypto: Driver conversions for DMA alignment | expand |
On 2022/12/2 17:19, 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. > > 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. > Hi, Herbert: There are also skcipher_request_ctx and aead_request_ctx in the hisilicon/sec2 driver that need to be updated. Thanks, Longfang. > Thanks, >
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,
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?
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,
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).
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,