[PATCH v2] dmaengine: qcom: gpi: Fix channel cleanup in unwind path

[PATCH v2] dmaengine: qcom: gpi: Fix channel cleanup in unwind path

[Aniket Randive]

The gpi_ch_init() error path has three bugs: sibling channels are
not fully reset and deallocated, the event ring pm_state is left
stale after being freed, and ch_ring leaks if gpi_ch_init() fails.

Fix the unwind loops in error_start_chan and error_alloc_chan to
iterate over gpii->gchan[i] instead of the original gchan pointer,
so each sibling channel is properly reset and deallocated.

Restore pm_state to DISABLE_STATE after freeing the event ring, so
gpi_free_chan_resources() does not attempt to free an already freed
ring or issue a redundant EV_CMD_DEALLOC.

Free ch_ring in gpi_alloc_chan_resources() if gpi_ch_init() fails,
since the ring is allocated before the call and would otherwise leak.

Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com>
---
Changes in v2:
- Updated the commit message as per Mukesh suggestion.
---
 drivers/dma/qcom/gpi.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
index a5055a6273af..c41bfac65ddf 100644
--- a/drivers/dma/qcom/gpi.c
+++ b/drivers/dma/qcom/gpi.c
@@ -1965,16 +1965,19 @@ static int gpi_ch_init(struct gchan *gchan)
 error_start_chan:
 	for (i = i - 1; i >= 0; i--) {
 		gpi_stop_chan(&gpii->gchan[i]);
-		gpi_send_cmd(gpii, gchan, GPI_CH_CMD_RESET);
+		gpi_send_cmd(gpii, &gpii->gchan[i], GPI_CH_CMD_RESET);
 	}
 	i = 2;
 error_alloc_chan:
 	for (i = i - 1; i >= 0; i--)
-		gpi_reset_chan(gchan, GPI_CH_CMD_DE_ALLOC);
+		gpi_reset_chan(&gpii->gchan[i], GPI_CH_CMD_DE_ALLOC);
 error_alloc_ev_ring:
 	gpi_disable_interrupts(gpii);
 error_config_int:
 	gpi_free_ring(&gpii->ev_ring, gpii);
+	write_lock_irq(&gpii->pm_lock);
+	gpii->pm_state = DISABLE_STATE;
+	write_unlock_irq(&gpii->pm_lock);
 exit_gpi_init:
 	return ret;
 }
@@ -2065,6 +2068,8 @@ static int gpi_alloc_chan_resources(struct dma_chan *chan)
 		goto xfer_alloc_err;
 
 	ret = gpi_ch_init(gchan);
+	if (ret)
+		gpi_free_ring(&gchan->ch_ring, gpii);
 
 	mutex_unlock(&gpii->ctrl_lock);
 

---
base-commit: 415606a7be939835db9b0d6b711887586646346d
change-id: 20260803-gpi_bug_fix-b0b80ef315b5

Best regards,
--  
Aniket Randive <aniket.randive@oss.qualcomm.com>

Re: [PATCH v2] dmaengine: qcom: gpi: Fix channel cleanup in unwind path

[Mukesh Savaliya]

On 8/10/2026 12:21 PM, Aniket Randive wrote:
> The gpi_ch_init() error path has three bugs: sibling channels are
May be instead of three bugs, can actually mention issues
"start here mentioning  the three problems first in generic way."
is what i mentioned, not like write numbers :) .

May be misunderstood.

> not fully reset and deallocated, the event ring pm_state is left
> stale after being freed, and ch_ring leaks if gpi_ch_init() fails.
> 
> Fix the unwind loops in error_start_chan and error_alloc_chan to
> iterate over gpii->gchan[i] instead of the original gchan pointer,
> so each sibling channel is properly reset and deallocated.
> 
> Restore pm_state to DISABLE_STATE after freeing the event ring, so
> gpi_free_chan_resources() does not attempt to free an already freed
> ring or issue a redundant EV_CMD_DEALLOC.
> 
> Free ch_ring in gpi_alloc_chan_resources() if gpi_ch_init() fails,
> since the ring is allocated before the call and would otherwise leak.
> 
> Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com>
> ---

Review if below looks fine, you may modify/change if anything wrong.

you may wait for other's review and make changes together. Do not upload 
v3 only for this immediately.

Title: Fix resource leaks in gpi_ch_init() error paths

The gpi_ch_init() unwind paths do not clean up resources correctly when
channel initialization fails.

The error_start_chan and error_alloc_chan labels iterate over the
original channel pointer instead of the channels stored in gpii->gchan[].
As a result, previously initialized sibling channels are not properly
reset and deallocated.

The event ring PM state is also left unchanged after the ring is freed.
Subsequent cleanup through gpi_free_chan_resources() may therefore
attempt to free the already released ring and issue a redundant
EV_CMD_DEALLOC command.

Additionally, gpi_alloc_chan_resources() allocates ch_ring before
calling gpi_ch_init(), but does not release it when gpi_ch_init() fails,
resulting in a memory leak.

Fix the unwind paths to operate on the correct channels, restore the
event ring PM state after freeing the ring, and release ch_ring when
channel initialization fails.