Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Le Mon, Mar 07, 2022 at 02:56:21PM +0100, Corentin Labbe a écrit : > Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe > > wrote: > > > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +, Robin Murphy a écrit : > > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu > > > > >> wrote: > > > > >>> > > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > >>>> > > > > >>>> Hello > > > > >>>> > > > > >>>> I got: > > > > >>>> [ 17.563793] [ cut here ] > > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees > > > > >>>> DMA memory with different direction [device > > > > >>>> address=0x78fe5800] [size=8 bytes] [mapped with > > > > >>>> DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > > >>> > > > > >>> The direction argument during unmap must match whatever direction > > > > >>> you used during the original map call. > > > > >> > > > > >> > > > > >> Yes, of course. I changed one but forgot the other. > > > > >> > > > > >> Corentin, could you be kind and check that this solves the original > > > > >> problem and does not produce new warnings? > > > > >> > > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> index 11e0278c8631..31cfe014922e 100644 > > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device > > > > >> *dev, > > > > >> void *ctx, > > > > >>req_ctx->mlli_params.mlli_dma_addr); > > > > >> } > > > > >> > > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > >> - > > > > >> if (src != dst) { > > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, > > > > >> DMA_BIDIRECTIONAL); > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > > > > >> DMA_TO_DEVICE); > > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, > > > > >> DMA_FROM_DEVICE); > > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", > > > > >> sg_virt(dst)); > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", > > > > >> sg_virt(src)); > > > > >> + } else { > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > > > > >> DMA_BIDIRECTIONAL); > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", > > > > >> sg_virt(src)); > > > > >> } > > > > >> } > > > > >> > > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> u32 dummy = 0; > > > > >> int rc = 0; > > > > >> u32 mapped_nents = 0; > > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : > > > > >> DMA_BIDIRECTIONAL); > > > > >> > > > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > > > >> mlli_params->curr_pool = NULL; > > > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> } > > > > >> > > > > >> /* Map the src SGL */ > > > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BI
Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Le Mon, Mar 07, 2022 at 04:00:44PM +0200, Gilad Ben-Yossef a écrit : > On Mon, Mar 7, 2022 at 3:56 PM Corentin Labbe > wrote: > > > > Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > > > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe > > > wrote: > > > > > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +, Robin Murphy a écrit : > > > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a > > > > > > ďż˝crit : > > > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu > > > > > >> wrote: > > > > > >>> > > > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > > >>>> > > > > > >>>> Hello > > > > > >>>> > > > > > >>>> I got: > > > > > >>>> [ 17.563793] [ cut here ] > > > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver > > > > > >>>> frees DMA memory with different direction [device > > > > > >>>> address=0x78fe5800] [size=8 bytes] [mapped with > > > > > >>>> DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > > > >>> > > > > > >>> The direction argument during unmap must match whatever direction > > > > > >>> you used during the original map call. > > > > > >> > > > > > >> > > > > > >> Yes, of course. I changed one but forgot the other. > > > > > >> > > > > > >> Corentin, could you be kind and check that this solves the original > > > > > >> problem and does not produce new warnings? > > > > > >> > > > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> index 11e0278c8631..31cfe014922e 100644 > > > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device > > > > > >> *dev, > > > > > >> void *ctx, > > > > > >>req_ctx->mlli_params.mlli_dma_addr); > > > > > >> } > > > > > >> > > > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, > > > > > >> DMA_BIDIRECTIONAL); > > > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > > >> - > > > > > >> if (src != dst) { > > > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, > > > > > >> DMA_BIDIRECTIONAL); > > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > > > > > >> DMA_TO_DEVICE); > > > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, > > > > > >> DMA_FROM_DEVICE); > > > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", > > > > > >> sg_virt(dst)); > > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", > > > > > >> sg_virt(src)); > > > > > >> + } else { > > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > > > > > >> DMA_BIDIRECTIONAL); > > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", > > > > > >> sg_virt(src)); > > > > > >> } > > > > > >> } > > > > > >> > > > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > > >> *drvdata, void *ctx, > > > > > >> u32 dummy = 0; > > > > > >> int rc = 0; > > > > > >> u32 mapped_nents = 0; > > > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : > > > > > >> DMA_BIDIRECTIONAL); > > > > >
Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe > wrote: > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +, Robin Murphy a écrit : > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu > > > >> wrote: > > > >>> > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > >>>> > > > >>>> Hello > > > >>>> > > > >>>> I got: > > > >>>> [ 17.563793] [ cut here ] > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees > > > >>>> DMA memory with different direction [device > > > >>>> address=0x78fe5800] [size=8 bytes] [mapped with > > > >>>> DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > >>> > > > >>> The direction argument during unmap must match whatever direction > > > >>> you used during the original map call. > > > >> > > > >> > > > >> Yes, of course. I changed one but forgot the other. > > > >> > > > >> Corentin, could you be kind and check that this solves the original > > > >> problem and does not produce new warnings? > > > >> > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> index 11e0278c8631..31cfe014922e 100644 > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > > >> void *ctx, > > > >>req_ctx->mlli_params.mlli_dma_addr); > > > >> } > > > >> > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > >> - > > > >> if (src != dst) { > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, > > > >> DMA_BIDIRECTIONAL); > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > > > >> DMA_TO_DEVICE); > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, > > > >> DMA_FROM_DEVICE); > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > >> + } else { > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > > > >> DMA_BIDIRECTIONAL); > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > >> } > > > >> } > > > >> > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > >> *drvdata, void *ctx, > > > >> u32 dummy = 0; > > > >> int rc = 0; > > > >> u32 mapped_nents = 0; > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : > > > >> DMA_BIDIRECTIONAL); > > > >> > > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > > >> mlli_params->curr_pool = NULL; > > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > >> *drvdata, void *ctx, > > > >> } > > > >> > > > >> /* Map the src SGL */ > > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, > > > >> &req_ctx->in_nents, > > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, > > > >> &req_ctx->in_nents, > > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, > > > >> &mapped_nents); > > > >> if (rc) > > > >> goto cipher_exit; > > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > >> *drvdata, void
Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Le Mon, Mar 07, 2022 at 01:59:00PM +0200, Gilad Ben-Yossef a écrit : > Hi Corentin, > > A bug in the DMA API it is not. > > What is the call site that calls into the crypto driver in your case? > Is it the drbg like in the cryptocell case or something else? > In my case, it is a user call from libkacpi test. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Le Mon, Mar 07, 2022 at 11:14:16AM +, Robin Murphy a écrit : > On 2022-03-07 10:48, Corentin Labbe wrote: > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu > >> wrote: > >>> > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > >>>> > >>>> Hello > >>>> > >>>> I got: > >>>> [ 17.563793] [ cut here ] > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA > >>>> memory with different direction [device address=0x78fe5800] > >>>> [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with > >>>> DMA_BIDIRECTIONAL] > >>> > >>> The direction argument during unmap must match whatever direction > >>> you used during the original map call. > >> > >> > >> Yes, of course. I changed one but forgot the other. > >> > >> Corentin, could you be kind and check that this solves the original > >> problem and does not produce new warnings? > >> > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > >> index 11e0278c8631..31cfe014922e 100644 > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > >> void *ctx, > >>req_ctx->mlli_params.mlli_dma_addr); > >> } > >> > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> - > >> if (src != dst) { > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, > >> DMA_BIDIRECTIONAL); > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, > >> DMA_FROM_DEVICE); > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> + } else { > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > >> DMA_BIDIRECTIONAL); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> } > >> } > >> > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> u32 dummy = 0; > >> int rc = 0; > >> u32 mapped_nents = 0; > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : > >> DMA_BIDIRECTIONAL); > >> > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > >> mlli_params->curr_pool = NULL; > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> > >> /* Map the src SGL */ > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, > >> &req_ctx->in_nents, > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, > >> &mapped_nents); > >> if (rc) > >> goto cipher_exit; > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> } else { > >> /* Map the dst sg */ > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > >> &req_ctx->out_nents, > >> LLI_MAX_NUM_OF_DATA_ENTRIES, > >> &dummy, &mapped_nents); > >> if (rc) > >> > >> > > > > Hello > > > > I still get the warning: > > [ 433.406230] [ cut here ] > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, > > overlapping mappings aren't supported > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at > > /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > [
Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Le Mon, Mar 07, 2022 at 11:14:16AM +, Robin Murphy a écrit : > On 2022-03-07 10:48, Corentin Labbe wrote: > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu > >> wrote: > >>> > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > >>>> > >>>> Hello > >>>> > >>>> I got: > >>>> [ 17.563793] [ cut here ] > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA > >>>> memory with different direction [device address=0x78fe5800] > >>>> [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with > >>>> DMA_BIDIRECTIONAL] > >>> > >>> The direction argument during unmap must match whatever direction > >>> you used during the original map call. > >> > >> > >> Yes, of course. I changed one but forgot the other. > >> > >> Corentin, could you be kind and check that this solves the original > >> problem and does not produce new warnings? > >> > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > >> index 11e0278c8631..31cfe014922e 100644 > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > >> void *ctx, > >>req_ctx->mlli_params.mlli_dma_addr); > >> } > >> > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> - > >> if (src != dst) { > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, > >> DMA_BIDIRECTIONAL); > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, > >> DMA_FROM_DEVICE); > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> + } else { > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, > >> DMA_BIDIRECTIONAL); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> } > >> } > >> > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> u32 dummy = 0; > >> int rc = 0; > >> u32 mapped_nents = 0; > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : > >> DMA_BIDIRECTIONAL); > >> > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > >> mlli_params->curr_pool = NULL; > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> > >> /* Map the src SGL */ > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, > >> &req_ctx->in_nents, > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, > >> &mapped_nents); > >> if (rc) > >> goto cipher_exit; > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> } else { > >> /* Map the dst sg */ > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > >> &req_ctx->out_nents, > >> LLI_MAX_NUM_OF_DATA_ENTRIES, > >> &dummy, &mapped_nents); > >> if (rc) > >> > >> > > > > Hello > > > > I still get the warning: > > [ 433.406230] [ cut here ] > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, > > overlapping mappings aren't supported > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at > > /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > [
Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a écrit : > On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu > wrote: > > > > On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > > > Hello > > > > > > I got: > > > [ 17.563793] [ cut here ] > > > [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA > > > memory with different direction [device address=0x78fe5800] > > > [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with > > > DMA_BIDIRECTIONAL] > > > > The direction argument during unmap must match whatever direction > > you used during the original map call. > > > Yes, of course. I changed one but forgot the other. > > Corentin, could you be kind and check that this solves the original > problem and does not produce new warnings? > > diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > b/drivers/crypto/ccree/cc_buffer_mgr.c > index 11e0278c8631..31cfe014922e 100644 > --- a/drivers/crypto/ccree/cc_buffer_mgr.c > +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > void *ctx, > req_ctx->mlli_params.mlli_dma_addr); > } > > - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > - > if (src != dst) { > - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > + } else { > + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > } > } > > @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > *drvdata, void *ctx, > u32 dummy = 0; > int rc = 0; > u32 mapped_nents = 0; > + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > mlli_params->curr_pool = NULL; > @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > *drvdata, void *ctx, > } > > /* Map the src SGL */ > - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, > &req_ctx->in_nents, > + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, >LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > if (rc) > goto cipher_exit; > @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > *drvdata, void *ctx, > } > } else { > /* Map the dst sg */ > - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, >&req_ctx->out_nents, > LLI_MAX_NUM_OF_DATA_ENTRIES, >&dummy, &mapped_nents); > if (rc) > > Hello I still get the warning: [ 433.406230] [ cut here ] [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 [ 433.406434] Modules linked in: [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) [ 433.406484] pstate: 4005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 433.406498] pc : add_dma_entry+0x1d0/0x288 [ 433.406510] lr : add_dma_entry+0x1d0/0x288 [ 433.406522] sp : 800015da3690 [ 433.406531] x29: 800015da3690 x28: x27: [ 433.406562] x26: x25: 8b4c7bc0 x24: 8b4c7000 [ 433.406593] x23: x22: ffef x21: 8a9b6000 [ 433.406623] x20: 0004c0af5c00 x19: 8b42 x18: [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 022e [ 433.406683] x14: 800015da3380 x13: ffea x12: 8b4be010 [ 433.406713] x11: 0001 x10: 0001 x9 : 8b4a6028 [ 433.406743]
Re: DMA mapping fill dma_address to 0
Le Wed, Apr 28, 2021 at 11:06:10AM +0100, Robin Murphy a écrit : > On 2021-04-28 09:42, Corentin Labbe wrote: > > Hello > > > > I work on the crypto offloader driver of cortina/gemini SL3516 SoC. > > I test it by filling a LUKS2 partition. > > I got a reproductible problem when handling skcipher requests. > > I use dma_map_sg() and when iterating other the result, sg_dma_address(sg) > > return 0. > > But sg_dma_len(sg) is still correct (4096 in my case). > > > > Below is a simplified view of my code: > > nr_sgs = dma_map_sg(ce->dev, areq->src, sg_nents(areq->src), DMA_TO_DEVICE); > > (nr_sgs = 1 in my case) > > sg = areq->src; > > if (!sg_dma_address(sg)) > > FAIL > > What is this check supposed to be for in the first place? 0 is a valid > DMA address, because it's also a valid physical address, and I recall > RAM at PA 0 on Hikey 960 flushing out some bugs in the past when we > tried to use 0 for DMA_MAPPING_ERROR. All the Gemini DTs appear to show > RAM starting at PA 0 too, so I'd have to guess that it's simply the case > that your DMA buffer happened to end up using that particular page. > > Robin. > Yes, 0 is a valid DMA address. I just find it by going further and printing mem_map value and testing it against sg_page() return. So my original problem was not related to this. Sorry for the noise. Thanks ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
DMA mapping fill dma_address to 0
Hello I work on the crypto offloader driver of cortina/gemini SL3516 SoC. I test it by filling a LUKS2 partition. I got a reproductible problem when handling skcipher requests. I use dma_map_sg() and when iterating other the result, sg_dma_address(sg) return 0. But sg_dma_len(sg) is still correct (4096 in my case). Below is a simplified view of my code: nr_sgs = dma_map_sg(ce->dev, areq->src, sg_nents(areq->src), DMA_TO_DEVICE); (nr_sgs = 1 in my case) sg = areq->src; if (!sg_dma_address(sg)) FAIL I have digged to find what do dma_map_sg() and I have added some debug. sg_page(sg) return c7efb000 for example so sg_page() works. But it seems the problem is that page_to_phys(sg_page(sg)) return 0. This problem does not appear immediatly, luksOpen and subsequent fsck always work. But it appears fast after, when mouting or rsync files in it. I have added CONFIG_DEBUG_SG, CONFIG_DMA_API_DEBUG, CONFIG_DMA_API_DEBUG_SG but they didnt bringed any more hints. Only "DMA-API: cacheline tracking ENOMEM, dma-debug disabled" appears but always with some "time" between my problem and its display. So I am not sure it is related. Regards ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: dma-api debugfs directory is not created since debugfs is not initialized
Le Tue, Apr 27, 2021 at 01:39:16PM +0200, Greg KH a écrit : > On Tue, Apr 27, 2021 at 01:34:27PM +0200, Corentin Labbe wrote: > > Hello > > > > I try to debug some DMA problem on next-20210427, and so I have enabled > > CONFIG_DMA_API_DEBUG=y. > > But the dma-api directory does show up in debugfs, but lot of other > > directory exists in it. > > Does it show up properly in 5.12? > No (Tested on a qemu x86_64) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
dma-api debugfs directory is not created since debugfs is not initialized
Hello I try to debug some DMA problem on next-20210427, and so I have enabled CONFIG_DMA_API_DEBUG=y. But the dma-api directory does show up in debugfs, but lot of other directory exists in it. After debugging it seems due to commit 56348560d495 ("debugfs: do not attempt to create a new file before the filesystem is initalized") Reverting the commit permit to "dma-api" debugfs to be found. (but seems not the right way to fix it). Regards ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: DMA-API: cacheline tracking ENOMEM, dma-debug disabled due to nouveau ?
On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: > > Hello > > > > Since lot of release (at least since 4.19), I hit the following error > > message: > > DMA-API: cacheline tracking ENOMEM, dma-debug disabled > > > > After hitting that, I try to check who is creating so many DMA mapping and > > see: > > cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c > > 6 ahci > > 257 e1000e > > 6 ehci-pci > >5891 nouveau > > 24 uhci_hcd > > > > Does nouveau having this high number of DMA mapping is normal ? > > Yeah seems perfectly fine for a gpu. Note that it never go down and when I terminate my X session, it stays the same. So without any "real" GPU work, does it is still normal to have so many active mapping ? For example, when doing some transfer, the ahci mapping number changes and then always go down to 6. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
DMA-API: cacheline tracking ENOMEM, dma-debug disabled due to nouveau ?
Hello Since lot of release (at least since 4.19), I hit the following error message: DMA-API: cacheline tracking ENOMEM, dma-debug disabled After hitting that, I try to check who is creating so many DMA mapping and see: cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c 6 ahci 257 e1000e 6 ehci-pci 5891 nouveau 24 uhci_hcd Does nouveau having this high number of DMA mapping is normal ? Regards ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] dma-debug: add dumping facility via debugfs
While debugging a DMA mapping leak, I needed to access debug_dma_dump_mappings() but easily from user space. This patch adds a /sys/kernel/debug/dma-api/dump file which contain all current DMA mapping. Signed-off-by: Corentin Labbe --- Changes since v1: - Use DEFINE_SHOW_ATTRIBUTE - Add Documentation Documentation/DMA-API.txt | 3 +++ kernel/dma/debug.c| 36 2 files changed, 39 insertions(+) diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index e133ccd60228..78114ee63057 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -696,6 +696,9 @@ dma-api/disabledThis read-only file contains the character 'Y' happen when it runs out of memory or if it was disabled at boot time +dma-api/dump This read-only file contains current DMA + mappings. + dma-api/error_countThis file is read-only and shows the total numbers of errors found. diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index 23cf5361bcf1..b4827b1c9070 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -144,6 +144,7 @@ static struct dentry *num_free_entries_dent __read_mostly; static struct dentry *min_free_entries_dent __read_mostly; static struct dentry *nr_total_entries_dent __read_mostly; static struct dentry *filter_dent __read_mostly; +static struct dentry *dump_dent __read_mostly; /* per-driver filter related state */ @@ -840,6 +841,36 @@ static const struct file_operations filter_fops = { .llseek = default_llseek, }; +static int dump_show(struct seq_file *seq, void *v) +{ + int idx; + + for (idx = 0; idx < HASH_SIZE; idx++) { + struct hash_bucket *bucket = &dma_entry_hash[idx]; + struct dma_debug_entry *entry; + unsigned long flags; + + spin_lock_irqsave(&bucket->lock, flags); + + list_for_each_entry(entry, &bucket->list, list) { + seq_printf(seq, + "%s %s %s idx %d P=%llx N=%lx D=%llx L=%llx %s %s\n", + dev_name(entry->dev), + dev_driver_string(entry->dev), + type2name[entry->type], idx, + phys_addr(entry), entry->pfn, + entry->dev_addr, entry->size, + dir2name[entry->direction], + maperr2str[entry->map_err_type]); + } + + spin_unlock_irqrestore(&bucket->lock, flags); + } + return 0; +} + +DEFINE_SHOW_ATTRIBUTE(dump); + static int dma_debug_fs_init(void) { dma_debug_dent = debugfs_create_dir("dma-api", NULL); @@ -894,6 +925,11 @@ static int dma_debug_fs_init(void) if (!filter_dent) goto out_err; + dump_dent = debugfs_create_file("dump", 0444, + dma_debug_dent, NULL, &dump_fops); + if (!dump_dent) + goto out_err; + return 0; out_err: -- 2.19.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] dma-debug: add dumping facility via debugfs
While debugging a DMA mapping leak, I needed to access debug_dma_dump_mappings() but easily from user space. This patch adds a /sys/kernel/debug/dma-api/dump file which contain all current DMA mapping. Signed-off-by: Corentin Labbe --- kernel/dma/debug.c | 47 ++ 1 file changed, 47 insertions(+) diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index 23cf5361bcf1..9253382f5729 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -144,6 +144,7 @@ static struct dentry *num_free_entries_dent __read_mostly; static struct dentry *min_free_entries_dent __read_mostly; static struct dentry *nr_total_entries_dent __read_mostly; static struct dentry *filter_dent __read_mostly; +static struct dentry *dump_dent __read_mostly; /* per-driver filter related state */ @@ -840,6 +841,47 @@ static const struct file_operations filter_fops = { .llseek = default_llseek, }; +static int dump_read(struct seq_file *seq, void *v) +{ + int idx; + + for (idx = 0; idx < HASH_SIZE; idx++) { + struct hash_bucket *bucket = &dma_entry_hash[idx]; + struct dma_debug_entry *entry; + unsigned long flags; + + spin_lock_irqsave(&bucket->lock, flags); + + list_for_each_entry(entry, &bucket->list, list) { + seq_printf(seq, + "%s %s %s idx %d P=%llx N=%lx D=%llx L=%llx %s %s\n", + dev_name(entry->dev), + dev_driver_string(entry->dev), + type2name[entry->type], idx, + phys_addr(entry), entry->pfn, + entry->dev_addr, entry->size, + dir2name[entry->direction], + maperr2str[entry->map_err_type]); + } + + spin_unlock_irqrestore(&bucket->lock, flags); + } + return 0; +} + +static int dump_open(struct inode *inode, struct file *file) +{ + return single_open(file, dump_read, inode->i_private); +} + +static const struct file_operations dump_fops = { + .owner = THIS_MODULE, + .open = dump_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + static int dma_debug_fs_init(void) { dma_debug_dent = debugfs_create_dir("dma-api", NULL); @@ -894,6 +936,11 @@ static int dma_debug_fs_init(void) if (!filter_dent) goto out_err; + dump_dent = debugfs_create_file("dump", 0444, + dma_debug_dent, NULL, &dump_fops); + if (!dump_dent) + goto out_err; + return 0; out_err: -- 2.19.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu