2014-04-18 00:57:19

by Joel Fernandes

[permalink] [raw]
Subject: [PATCH] [FIX] dmaengine: virt-dma: Free descriptor after callback

Free the vd (virt descriptor) after the callback is called. In EDMA driver
atleast which uses virt-dma, we make use of the desc during the callback and if
its dangerously freed before the callback is called. I also noticed this in
omap-dma dmaengine driver.

Cc: Vinod Koul <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Russell King <[email protected]>
Signed-off-by: Joel Fernandes <[email protected]>
---
drivers/dma/virt-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/virt-dma.c b/drivers/dma/virt-dma.c
index 6f80432..98aeb7f 100644
--- a/drivers/dma/virt-dma.c
+++ b/drivers/dma/virt-dma.c
@@ -84,10 +84,10 @@ static void vchan_complete(unsigned long arg)

list_del(&vd->node);

- vc->desc_free(vd);
-
if (cb)
cb(cb_data);
+
+ vc->desc_free(vd);
}
}

--
1.7.9.5


2014-04-18 08:51:10

by Russell King - ARM Linux

[permalink] [raw]
Subject: Re: [PATCH] [FIX] dmaengine: virt-dma: Free descriptor after callback

On Thu, Apr 17, 2014 at 07:56:50PM -0500, Joel Fernandes wrote:
> Free the vd (virt descriptor) after the callback is called. In EDMA driver
> atleast which uses virt-dma, we make use of the desc during the callback and if
> its dangerously freed before the callback is called. I also noticed this in
> omap-dma dmaengine driver.

You've missed the vital bit of information: why do you make use of the
descriptor afterwards? You shouldn't. omap-dma doesn't either.

Once clients submit their request to DMA engine, they must not hold any
kind of reference to the descriptor other than the cookie.

--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

2014-04-18 16:35:06

by Joel Fernandes

[permalink] [raw]
Subject: Re: [PATCH] [FIX] dmaengine: virt-dma: Free descriptor after callback

On 04/18/2014 03:50 AM, Russell King - ARM Linux wrote:
> On Thu, Apr 17, 2014 at 07:56:50PM -0500, Joel Fernandes wrote:
>> Free the vd (virt descriptor) after the callback is called. In EDMA driver
>> atleast which uses virt-dma, we make use of the desc during the callback and if
>> its dangerously freed before the callback is called. I also noticed this in
>> omap-dma dmaengine driver.
>
> You've missed the vital bit of information: why do you make use of the
> descriptor afterwards? You shouldn't. omap-dma doesn't either.
>
> Once clients submit their request to DMA engine, they must not hold any
> kind of reference to the descriptor other than the cookie.
>

Sorry, I confused edma/omap-dma callbacks for virt dma callbacks.

Anyway, I think there is still a chance in edma that we refer to the
echan->edesc pointer later on after virt-dma calls the free (in
edma_execute), so I'll just NULL that out to be safe and submit a patch.
Thanks.

regards,
-Joel

2014-04-22 16:26:10

by Vinod Koul

[permalink] [raw]
Subject: Re: [PATCH] [FIX] dmaengine: virt-dma: Free descriptor after callback

On Fri, Apr 18, 2014 at 11:34:50AM -0500, Joel Fernandes wrote:
> On 04/18/2014 03:50 AM, Russell King - ARM Linux wrote:
> > On Thu, Apr 17, 2014 at 07:56:50PM -0500, Joel Fernandes wrote:
> >> Free the vd (virt descriptor) after the callback is called. In EDMA driver
> >> atleast which uses virt-dma, we make use of the desc during the callback and if
> >> its dangerously freed before the callback is called. I also noticed this in
> >> omap-dma dmaengine driver.
> >
> > You've missed the vital bit of information: why do you make use of the
> > descriptor afterwards? You shouldn't. omap-dma doesn't either.
> >
> > Once clients submit their request to DMA engine, they must not hold any
> > kind of reference to the descriptor other than the cookie.
> >
>
> Sorry, I confused edma/omap-dma callbacks for virt dma callbacks.
>
> Anyway, I think there is still a chance in edma that we refer to the
> echan->edesc pointer later on after virt-dma calls the free (in
> edma_execute), so I'll just NULL that out to be safe and submit a patch.

Yes, that would be the right way :)

While looking at this, I see it is not called out specfically in documentation, will update
that as well

--
~Vinod