Re: [PATCH 2/2] dmaengine: rz-dmac: fix dead empty check in rz_dmac_chan_get_residue()

[sashiko-bot@kernel.org]

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

New issues:
- [High] The patch introduces a logic error that falsely reports pending unissued transfers as DMA_COMPLETE.

Pre-existing issues:
- [High] Race condition where unsubmitted descriptors are prematurely executed by the hardware.
--

commit 0e410e8d5063eb51746f71d6bfff0bc38f086e9b
Author: Maoyi Xie <maoyixie.tju@gmail.com>
Subject: dmaengine: rz-dmac: fix dead empty check in rz_dmac_chan_get_residue()

This commit changes list_first_entry to list_first_entry_or_null in
rz_dmac_chan_get_residue to properly check if the active list is empty.
If the list is empty, it now safely returns a zero residue instead of
reading from invalid neighboring memory.

> diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
> index 625ff29024de0..3dd76615881ff 100644
> --- a/drivers/dma/sh/rz-dmac.c
> +++ b/drivers/dma/sh/rz-dmac.c
> @@ -723,8 +723,8 @@ static u32 rz_dmac_chan_get_residue(struct rz_dmac_chan *channel,
>  	u32 crla, crtb, i;
>  
>  	/* Get current processing virtual descriptor */
> -	current_desc = list_first_entry(&channel->ld_active,
> -					struct rz_dmac_desc, node);
> +	current_desc = list_first_entry_or_null(&channel->ld_active,
> +						struct rz_dmac_desc, node);
>  	if (!current_desc)
>  		return 0;

[Severity: High]
If a client queries the status of a transfer that has been prepared but not
yet issued, or while it is pending in ld_queue waiting for previous
transfers, ld_active will be empty. With this patch, current_desc will be
null and the function will immediately return 0.

Does returning 0 residue here cause rz_dmac_tx_status() to prematurely
report the transfer as finished with a DMA_COMPLETE status?

Before this patch, the invalid pointer coincidentally bypassed the null
check, which allowed the code to continue, correctly search ld_queue, and
return the full descriptor length. Returning early here could cause
clients to free or reuse buffers while the hardware is still scheduled to
access them.

[Severity: High]
This is a pre-existing issue, but looking at how descriptors are queued,
is there a race condition where unsubmitted descriptors are prematurely
executed by the hardware?

In rz_dmac_prep_slave_sg() and rz_dmac_prep_dma_memcpy(), prepared
descriptors are immediately placed into channel->ld_queue before the
client calls dmaengine_submit(). If an existing transfer completes, the
hardware interrupt handler rz_dmac_irq_handler_thread() appears to blindly
pull the next descriptor from ld_queue and initiates the transfer via
rz_dmac_xfer_desc().

Could this result in the hardware executing transfers before the client
has filled the data buffers or actually submitted the transfer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521144755.3476353-1-maoyixie.tju@gmail.com?part=2