Re: [PATCH v2 52/64] dmaengine: tegra210-adma: kill vchan BH on teardown

[email protected] Mon, 27 Jul 2026 21:17:32 +0000
Newsgroups org.kernel.vger.dmaengine
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect ordering of bottom-half termination and IRQ freeing leaves a window for spurious execution and use-after-free.
- [High] Requesting the IRQ before powering up the device via Runtime PM causes a kernel panic if a pending or spurious interrupt fires.
--

--- Patch [52]: [PATCH v2 52/64] dmaengine: tegra210-adma: kill vchan BH on teardown ---
commit acf1e1ab4d7c08f6577663273485ed69a1d42e71
Author: Allen Pais <[email protected]>

dmaengine: tegra210-adma: kill vchan BH on teardown

Use dma_chan_kill_bh() for virt-dma cleanup.

> diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
> index ceaee1e33e68a..598abcc4edaa1 100644
> --- a/drivers/dma/tegra210-adma.c
> +++ b/drivers/dma/tegra210-adma.c
> @@ -811,7 +811,7 @@ static void tegra_adma_free_chan_resources(struct dma_chan *dc)
>  
>  	tegra_adma_terminate_all(dc);
>  	vchan_free_chan_resources(&tdc->vc);
> -	tasklet_kill(&tdc->vc.task);
> +	dma_chan_kill_bh(&tdc->vc.chan);
>  	free_irq(tdc->irq, tdc);

[Severity: High]
This is a pre-existing issue, but does this ordering leave a window for a
use-after-free?

If a delayed or spurious interrupt fires after dma_chan_kill_bh() flushes the
bottom-half, but before free_irq() unregisters the interrupt, couldn't the
interrupt handler execute and reschedule the bottom half via
vchan_cyclic_callback()?

Because free_irq() only waits for hardirq handlers and does not flush pending
bottom halves, this rescheduled bottom half could execute asynchronously after
the channel teardown completes and the client driver has freed its buffers.

Would it be safer to call free_irq() before dma_chan_kill_bh() to ensure
hardware events are disabled before flushing the work?

>  	pm_runtime_put(tdc2dev(tdc));
>  

[Severity: High]
This is also a pre-existing issue, but looking at the allocation side in
tegra_adma_alloc_chan_resources(), is it safe to request the IRQ before
powering up the device?

drivers/dma/tegra210-adma.c:tegra_adma_alloc_chan_resources() {
    ...
    ret = request_irq(tdc->irq, tegra_adma_isr, 0, dma_chan_name(dc), tdc);
    if (ret) {
        ...
    }

    ret = pm_runtime_resume_and_get(tdc2dev(tdc));
    ...
}

If the interrupt line is already active from a previous session or a spurious
hardware event, the CPU could immediately execute tegra_adma_isr() upon IRQ
registration.

Since tegra_adma_isr() unconditionally reads the ADMA_CH_INT_STATUS register,
and the device clock is disabled before pm_runtime_resume_and_get(), can
this access to unclocked hardware cause a synchronous external abort?

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=52