Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Tasklets created for DMA channels are not killed during driver removal, risking use-after-free panics if scheduled after devm allocations are freed. -- commit fe57b7262d586b3f961d1d34cf7a9a0acf70d3c7 Author: Frank Li <[email protected]> dmaengine: use dma_chan_name() helper to get per-channel device name This commit updates various DMA engine drivers to use the existing dma_chan_name() helper instead of open-coding the per-channel device name retrieval. The change simplifies the code and improves consistency across the subsystem without altering functionality. [ ... ] > diff --git a/drivers/dma/loongson/loongson2-apb-dma.c > b/drivers/dma/loongson/loongson2-apb-dma.c > index aceb069e71fca..7c3d7c3273955 100644 > --- a/drivers/dma/loongson/loongson2-apb-dma.c > +++ b/drivers/dma/loongson/loongson2-apb-dma.c > @@ -282,7 +282,7 @@ static int ls2x_dma_alloc_chan_resources(struct dma_chan > *chan) > struct ls2x_dma_chan *lchan = to_ldma_chan(chan); > > /* Create a pool of consistent memory blocks for hardware descriptors */ > - lchan->pool = dma_pool_create(dev_name(chan2dev(chan)), > + lchan->pool = dma_pool_create(dma_chan_name(chan), > chan->device->dev, PAGE_SIZE, > __alignof__(struct ls2x_dma_hw_desc), 0); > if (!lchan->pool) { [Severity: High] This isn't a bug introduced by this patch, but I noticed a pre-existing issue in ls2x_dma_remove() missing tasklet cleanup. Should ls2x_dma_remove() iterate over the channels and call tasklet_kill(&chan->vchan.task) before returning? The driver relies on devm allocations for channel memory, which are automatically freed immediately after remove() completes. If the DMA driver is unbound shortly after an interrupt fires, the interrupt handler schedules the channel's tasklet. If this scheduled tasklet executes after the memory is freed, can it dereference invalid memory and cause a use-after-free panic? [ ... ] > diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c > index 386e85cd4882a..6b29e15b0616c 100644 > --- a/drivers/dma/mmp_pdma.c > +++ b/drivers/dma/mmp_pdma.c > @@ -565,7 +565,7 @@ static int mmp_pdma_alloc_chan_resources(struct dma_chan > *dchan) > if (chan->desc_pool) > return 1; > > - chan->desc_pool = dma_pool_create(dev_name(&dchan->dev->device), > + chan->desc_pool = dma_pool_create(dma_chan_name(dchan), > chan->dev, > sizeof(struct mmp_pdma_desc_sw), > __alignof__(struct mmp_pdma_desc_sw), [Severity: High] This isn't a bug introduced by this patch, but there appears to be a similar pre-existing issue in mmp_pdma_remove(). Does mmp_pdma_remove() also need a loop over the channels to call tasklet_kill(&chan->tasklet)? Like the Loongson driver, this driver also uses devm allocations for channel structures and could experience a use-after-free panic if a tasklet runs after mmp_pdma_remove() finishes and the memory is freed. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
