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
