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

Hi Peng,

At 2026-10-20 15:36:19, "Peng Fan (OSS)" [off-list ref] wrote:

On Sun, 18 Oct 2026 12:07:16 +0800 Jiale Yao [off-list ref] wrote:

quoted

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

quoted

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

-- 
2.34.1

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

Thanks,
Jiale