Re: [PATCH 3/6] dmaengine: zynqmp_dma: Fix stale kerneldoc comments

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Double-free and list corruption due to dropping the lock during safe list traversal in zynqmp_dma_chan_desc_cleanup.
--

--- Patch [3]: [PATCH 3/6] dmaengine: zynqmp_dma: Fix stale kerneldoc comments ---
commit 3c8d64c77aae165a12708426042a7a72be1ba044
Author: Golla Nagendra <[email protected]>

dmaengine: zynqmp_dma: Fix stale kerneldoc comments

This commit updates various kerneldoc comments across the zynqmp_dma driver.
It corrects parameter descriptions and return values that no longer matched
the actual code implementation.

> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index f7e4a177bd17e..c5b05fd52e9d8 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c

[ ... ]

> @@ -617,7 +617,6 @@ static void zynqmp_dma_start_transfer(struct zynqmp_dma_chan *chan)
>  	zynqmp_dma_start(chan);
>  }
>  
> -
>  /**
>   * zynqmp_dma_chan_desc_cleanup - Cleanup the completed descriptors
>   * @chan: ZynqMP DMA channel

[Severity: High]
This is a pre-existing issue, but can dropping the lock during safe list
traversal in zynqmp_dma_chan_desc_cleanup() cause a double-free or list
corruption?

If CPU1 is running zynqmp_dma_chan_desc_cleanup(), it drops chan->lock
to invoke the callback:

	list_for_each_entry_safe(desc, next, &chan->done_list, node) {
		...
		if (dmaengine_desc_callback_valid(&cb)) {
			spin_unlock_irqrestore(&chan->lock, irqflags);
			dmaengine_desc_callback_invoke(&cb, NULL);
			spin_lock_irqsave(&chan->lock, irqflags);
		}

While the lock is dropped, if a concurrent call to
zynqmp_dma_device_terminate_all() on CPU2 acquires the lock and frees
the descriptors, it would move all items from done_list to free_list.

When CPU1 reacquires the lock, it calls zynqmp_dma_free_descriptor(chan, desc)
on the already freed desc. This would double-increment chan->desc_free_cnt.
Furthermore, the loop would continue using the cached next pointer which
is now part of the free_list, potentially causing it to traverse the wrong
list and process freed descriptors.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3