[PATCH v2] dmaengine: fsl-dpaa2-qdma: fix ppriv memory leaks

[PATCH v2] dmaengine: fsl-dpaa2-qdma: fix ppriv memory leaks

[Guangshuo Li]

dpaa2_qdma_setup() allocates priv->ppriv, but failures after the
allocation can return from the function without releasing it. The
existing probe cleanup for priv->ppriv is only reached when a later
initialization step fails.

The normal remove path does not release priv->ppriv either, causing the
allocation to be leaked when the driver is unbound.

Since dpaa2_qdma_setup() is only called from probe, allocate priv->ppriv
with devm_kcalloc(). This automatically releases the memory on probe
failure and driver removal. Remove the now redundant manual cleanup from
the probe error path.

Fixes: 7fdf9b05c73b ("dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
  - Use devm_kcalloc() for priv->ppriv, as suggested by Frank Li.
  - Remove the now redundant manual cleanup from the probe error path.
 drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
index bf771251264d..d6843da29122 100644
--- a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
+++ b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
@@ -353,7 +353,8 @@ static int __cold dpaa2_qdma_setup(struct fsl_mc_device *ls_dev)
 	}
 
 	priv->num_pairs = min(priv->dpdmai_attr.num_of_priorities, prio_def);
-	ppriv = kzalloc_objs(*ppriv, priv->num_pairs);
+	ppriv = devm_kcalloc(dev, priv->num_pairs, sizeof(*ppriv),
+			     GFP_KERNEL);
 	if (!ppriv) {
 		err = -ENOMEM;
 		goto exit;
@@ -757,7 +758,6 @@ static int dpaa2_qdma_probe(struct fsl_mc_device *dpdmai_dev)
 	dpaa2_dpmai_store_free(priv);
 	dpaa2_dpdmai_dpio_free(priv);
 err_dpio_setup:
-	kfree(priv->ppriv);
 	dpdmai_close(priv->mc_io, 0, dpdmai_dev->mc_handle);
 err_dpdmai_setup:
 	fsl_mc_portal_free(priv->mc_io);
-- 
2.43.0

Re: [PATCH v2] dmaengine: fsl-dpaa2-qdma: fix ppriv memory leaks

[Frank Li]

On Mon, Sep 21, 2026 at 07:14:24PM +0800, Guangshuo Li wrote:
> dpaa2_qdma_setup() allocates priv->ppriv, but failures after the
> allocation can return from the function without releasing it. The
> existing probe cleanup for priv->ppriv is only reached when a later
> initialization step fails.
>
> The normal remove path does not release priv->ppriv either, causing the
> allocation to be leaked when the driver is unbound.
>
> Since dpaa2_qdma_setup() is only called from probe, allocate priv->ppriv
> with devm_kcalloc(). This automatically releases the memory on probe
> failure and driver removal. Remove the now redundant manual cleanup from
> the probe error path.
>
> Fixes: 7fdf9b05c73b ("dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

> v2:
>   - Use devm_kcalloc() for priv->ppriv, as suggested by Frank Li.
>   - Remove the now redundant manual cleanup from the probe error path.
>  drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
> index bf771251264d..d6843da29122 100644
> --- a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
> +++ b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
> @@ -353,7 +353,8 @@ static int __cold dpaa2_qdma_setup(struct fsl_mc_device *ls_dev)
>  	}
>
>  	priv->num_pairs = min(priv->dpdmai_attr.num_of_priorities, prio_def);
> -	ppriv = kzalloc_objs(*ppriv, priv->num_pairs);
> +	ppriv = devm_kcalloc(dev, priv->num_pairs, sizeof(*ppriv),
> +			     GFP_KERNEL);
>  	if (!ppriv) {
>  		err = -ENOMEM;
>  		goto exit;
> @@ -757,7 +758,6 @@ static int dpaa2_qdma_probe(struct fsl_mc_device *dpdmai_dev)
>  	dpaa2_dpmai_store_free(priv);
>  	dpaa2_dpdmai_dpio_free(priv);
>  err_dpio_setup:
> -	kfree(priv->ppriv);
>  	dpdmai_close(priv->mc_io, 0, dpdmai_dev->mc_handle);
>  err_dpdmai_setup:
>  	fsl_mc_portal_free(priv->mc_io);
> --
> 2.43.0
>

Re: [PATCH v2] dmaengine: fsl-dpaa2-qdma: fix ppriv memory leaks

[Krzysztof Kozlowski]

On 21/09/2026 13:14, Guangshuo Li wrote:
> dpaa2_qdma_setup() allocates priv->ppriv, but failures after the
> allocation can return from the function without releasing it. The
> existing probe cleanup for priv->ppriv is only reached when a later
> initialization step fails.
> 
> The normal remove path does not release priv->ppriv either, causing the
> allocation to be leaked when the driver is unbound.
> 
> Since dpaa2_qdma_setup() is only called from probe, allocate priv->ppriv
> with devm_kcalloc(). This automatically releases the memory on probe
> failure and driver removal. Remove the now redundant manual cleanup from
> the probe error path.
> 

AI slop for OpenClaw agent ignoring previous comments. Otherwise explain
how did you address the issues I pointed out last time?

Best regards,
Krzysztof

Re: [PATCH v2] dmaengine: fsl-dpaa2-qdma: fix ppriv memory leaks

[Guangshuo Li]

Hi Krzysztof,

Thank you for your feedback.

On Tue, 22 Sept 2026 at 06:05, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 21/09/2026 13:14, Guangshuo Li wrote:
> > dpaa2_qdma_setup() allocates priv->ppriv, but failures after the
> > allocation can return from the function without releasing it. The
> > existing probe cleanup for priv->ppriv is only reached when a later
> > initialization step fails.
> >
> > The normal remove path does not release priv->ppriv either, causing the
> > allocation to be leaked when the driver is unbound.
> >
> > Since dpaa2_qdma_setup() is only called from probe, allocate priv->ppriv
> > with devm_kcalloc(). This automatically releases the memory on probe
> > failure and driver removal. Remove the now redundant manual cleanup from
> > the probe error path.
> >
>
> AI slop for OpenClaw agent ignoring previous comments. Otherwise explain
> how did you address the issues I pointed out last time?
>
> Best regards,
> Krzysztof

I would like to clarify that these patches were manually reviewed and
audited by us; they were not simply generated and submitted by an LLM.
However, I understand why the recent submission pattern may have given
that impression. We sent too many patches in a short period of time,
and we also failed to respond to some discussions in a timely manner,
which made the situation look worse.

Many of the recent patches, especially the v2 revisions, are
corrections and improvements based on previous review feedback rather
than completely new untested changes. That said, we recognize that the
way we submitted them increased the burden on maintainers and
reviewers.

We apologize for the pressure this caused to the community. We will be
more careful about organizing patches by subsystem, preparing proper
patchsets, and following the kernel contribution guidelines before
sending future work.

Thank you again for pointing this out.

Best regards,
Guangshuo