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

["Peng Fan (OSS)" <peng.fan@oss.nxp.com>]

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)