[PATCH 0/7] dmaengine: drain completion tasklets during teardown

[PATCH 0/7] dmaengine: drain completion tasklets during teardown

[Jiale Yao]

Several DMAengine drivers defer interrupt completion processing to
tasklets, but release channel resources without draining tasklets that
were already queued. Stopping or releasing an IRQ prevents new hard IRQ
handlers, but does not synchronize the deferred tasklet.

Depending on the driver, a late tasklet can access freed descriptor
storage or invoke a completion callback after its client data has been
released. Ensure each producer is stopped before killing the tasklet and
freeing the resources it can access.

Each patch is independent and keeps the synchronization local to one
driver's channel or device teardown path.

Jiale Yao (7):
  dmaengine: ep93xx: drain tasklet before freeing channel resources
  dmaengine: fsldma: drain channel tasklet during removal
  dmaengine: mmp_pdma: drain channel tasklets during removal
  dmaengine: mmp_tdma: synchronize tasklet when freeing a channel
  dmaengine: mv_xor: drain IRQ tasklet before freeing channel memory
  dmaengine: mxs-dma: synchronize tasklet when freeing a channel
  dmaengine: ste_dma40: synchronize tasklet when releasing a channel

 drivers/dma/ep93xx_dma.c | 4 +++-
 drivers/dma/fsldma.c     | 1 +
 drivers/dma/mmp_pdma.c   | 4 ++++
 drivers/dma/mmp_tdma.c   | 2 ++
 drivers/dma/mv_xor.c     | 6 ++++--
 drivers/dma/mxs-dma.c    | 1 +
 drivers/dma/ste_dma40.c  | 2 ++
 7 files changed, 17 insertions(+), 3 deletions(-)

-- 
2.34.1

[PATCH 2/7] dmaengine: fsldma: drain channel tasklet during removal

[Jiale Yao]

The channel IRQ schedules a tasklet that accesses the channel descriptor
lists. Device removal frees the IRQs and then releases each channel
without draining tasklets that were already queued.

Kill each channel tasklet before unmapping and freeing the channel. The
removal path has already freed all controller or channel IRQs, so no
interrupt handler can queue the tasklet again.

Fixes: 173acc7ce853 ("dmaengine: add driver for Freescale MPC85xx DMA controller")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 drivers/dma/fsldma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 22d62d958abd..0e2f84862261 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1205,6 +1205,7 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
 
 static void fsl_dma_chan_remove(struct fsldma_chan *chan)
 {
+	tasklet_kill(&chan->tasklet);
 	irq_dispose_mapping(chan->irq);
 	list_del(&chan->common.device_node);
 	iounmap(chan->regs);
-- 
2.34.1

Re: [PATCH 0/7] dmaengine: drain completion tasklets during teardown

[Peng Fan (OSS)]

On Sun, 18 Oct 2026 12:07:16 +0800 Jiale Yao <yaojiale02@163.com> wrote:

> Several DMAengine drivers defer interrupt completion processing to
> tasklets, but release channel resources without draining tasklets that
> were already queued. Stopping or releasing an IRQ prevents new hard IRQ
> handlers, but does not synchronize the deferred tasklet.
> 
> Depending on the driver, a late tasklet can access freed descriptor
> storage or invoke a completion callback after its client data has been
> released. Ensure each producer is stopped before killing the tasklet and
> freeing the resources it can access.
> 
> Each patch is independent and keeps the synchronization local to one
> driver's channel or device teardown path.
> 
> Jiale Yao (7):
>   dmaengine: ep93xx: drain tasklet before freeing channel resources
>   dmaengine: fsldma: drain channel tasklet during removal
>   dmaengine: mmp_pdma: drain channel tasklets during removal
>   dmaengine: mmp_tdma: synchronize tasklet when freeing a channel
>   dmaengine: mv_xor: drain IRQ tasklet before freeing channel memory
>   dmaengine: mxs-dma: synchronize tasklet when freeing a channel
>   dmaengine: ste_dma40: synchronize tasklet when releasing a channel
> 
>  drivers/dma/ep93xx_dma.c | 4 +++-
>  drivers/dma/fsldma.c     | 1 +
>  drivers/dma/mmp_pdma.c   | 4 ++++
>  drivers/dma/mmp_tdma.c   | 2 ++
>  drivers/dma/mv_xor.c     | 6 ++++--
>  drivers/dma/mxs-dma.c    | 1 +
>  drivers/dma/ste_dma40.c  | 2 ++

You might need to add a bit more context on the issues.

Taking mxs-dma for example, it is non-SMP processor.

The normal completion path is:
1. DMA hardirq fires -> mxs_dma_int_handler() -> tasklet_schedule() -> raises TASKLET_SOFTIRQ
2. irq_exit() -> softirq processing -> tasklet_action() -> mxs_dma_tasklet() runs
3. Return to process context

The tasklet almost always completes before process context resumes.
The only way to hit the race on UP is if softirq processing gets deferred
to ksoftirqd, and then:
In PREEMPT_RT case: Tasklets become threaded and can interleave.
Is there a chance that in non-RT case, could we hit issues on UP processor?

Or I may understand wrong?

Regards
Peng

>  7 files changed, 17 insertions(+), 3 deletions(-)
> 
> -- 
> 2.34.1

Sent using hkml (https://github.com/sjp38/hackermail)

Re:Re: [PATCH 0/7] dmaengine: drain completion tasklets during teardown

[jiale yao]

Hi Peng,

At 2026-10-20 15:36:19, "Peng Fan (OSS)" <peng.fan@oss.nxp.com> wrote:
>On Sun, 18 Oct 2026 12:07:16 +0800 Jiale Yao <yaojiale02@163.com> wrote:
>
>> Several DMAengine drivers defer interrupt completion processing to
>> tasklets, but release channel resources without draining tasklets that
>> were already queued. Stopping or releasing an IRQ prevents new hard IRQ
>> handlers, but does not synchronize the deferred tasklet.
>> 
>> Depending on the driver, a late tasklet can access freed descriptor
>> storage or invoke a completion callback after its client data has been
>> released. Ensure each producer is stopped before killing the tasklet and
>> freeing the resources it can access.
>> 
>> Each patch is independent and keeps the synchronization local to one
>> driver's channel or device teardown path.
>> 
>> Jiale Yao (7):
>>   dmaengine: ep93xx: drain tasklet before freeing channel resources
>>   dmaengine: fsldma: drain channel tasklet during removal
>>   dmaengine: mmp_pdma: drain channel tasklets during removal
>>   dmaengine: mmp_tdma: synchronize tasklet when freeing a channel
>>   dmaengine: mv_xor: drain IRQ tasklet before freeing channel memory
>>   dmaengine: mxs-dma: synchronize tasklet when freeing a channel
>>   dmaengine: ste_dma40: synchronize tasklet when releasing a channel
>> 
>>  drivers/dma/ep93xx_dma.c | 4 +++-
>>  drivers/dma/fsldma.c     | 1 +
>>  drivers/dma/mmp_pdma.c   | 4 ++++
>>  drivers/dma/mmp_tdma.c   | 2 ++
>>  drivers/dma/mv_xor.c     | 6 ++++--
>>  drivers/dma/mxs-dma.c    | 1 +
>>  drivers/dma/ste_dma40.c  | 2 ++
>
>You might need to add a bit more context on the issues.
>
>Taking mxs-dma for example, it is non-SMP processor.
>
>The normal completion path is:
>1. DMA hardirq fires -> mxs_dma_int_handler() -> tasklet_schedule() -> raises TASKLET_SOFTIRQ
>2. irq_exit() -> softirq processing -> tasklet_action() -> mxs_dma_tasklet() runs
>3. Return to process context
>
>The tasklet almost always completes before process context resumes.
>The only way to hit the race on UP is if softirq processing gets deferred
>to ksoftirqd, and then:
>In PREEMPT_RT case: Tasklets become threaded and can interleave.
>Is there a chance that in non-RT case, could we hit issues on UP processor?
>
>Or I may understand wrong?

Thanks for the detailed analysis.

The normal UP/non-RT path usually runs the tasklet from irq_exit(), as
you described. However, if the DMA IRQ raises TASKLET_SOFTIRQ after that
vector has already been processed in the current softirq pass,
need_resched() or the softirq time/restart limits can defer it to
ksoftirqd. Process context may then release the channel before the
tasklet runs.

A similar teardown issue was fixed by commit 0ca79979384f
("RDMA/erdma: Fix CEQ tasklet use-after-free on removal"). free_irq()
synchronizes the hard IRQ handler, but does not drain an already queued
tasklet.

For mxs-dma, the deferred tasklet may invoke the completion callback
after its client data has been released. Therefore this can also happen
on UP/non-RT, although the window is narrow.

>
>Regards
>Peng
>
>>  7 files changed, 17 insertions(+), 3 deletions(-)
>> 
>> -- 
>> 2.34.1
>
>Sent using hkml (https://github.com/sjp38/hackermail)


Thanks,
Jiale