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

On Sun, 18 Oct 2026 12:07:16 +0800 Jiale Yao [off-list ref] 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)