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@xxxxxxxxxxx> wrote:
>On Sun, 18 Oct 2026 12:07:16 +0800 Jiale Yao <yaojiale02@xxxxxxx> 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