mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chang, Jianpeng (CN)" <Jianpeng.Chang.CN@windriver.com>
To: Breno Leitao <leitao@debian.org>
Cc: horia.geanta@nxp.com, pankaj.gupta@nxp.com, gaurav.jain@nxp.com,
	herbert@gondor.apana.org.au, davem@davemloft.net,
	kuba@kernel.org, linux-crypto@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crypto: caam: fix netdev memory leak in dpaa2_caam_probe
Date: Fri, 16 Jan 2026 18:14:37 +0800	[thread overview]
Message-ID: <4a5b1ada-0602-4f43-b09b-ba1a8da26f21@windriver.com> (raw)
In-Reply-To: <4h7joiwvamq3sgrkhyemtug4lucyicnx7beuik3i5foydwb256@iemjvkrs7h2d>



On 1/16/2026 5:46 PM, Breno Leitao wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> On Fri, Jan 16, 2026 at 09:44:55AM +0800, Jianpeng Chang wrote:
>> When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in
>> dpaa2") converted embedded net_device to dynamically allocated pointers,
>> it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in
>> dpaa2_dpseci_free() for error paths.
>>
>> This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe
>> due to DPIO devices not being ready yet. The kernel's deferred probe
>> mechanism handles the retry successfully, but the netdevs allocated during
>> the failed probe attempt are never freed, resulting in kmemleak reports
>> showing multiple leaked netdev-related allocations all traced back to
>> dpaa2_caam_probe().
>>
>> Fix this by preserving the CPU mask of allocated netdevs during setup and
>> using it for cleanup in dpaa2_dpseci_free(). This approach ensures that
>> only the CPUs that actually had netdevs allocated will be cleaned up,
>> avoiding potential issues with CPU hotplug scenarios.
>>
>> Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2")
>> Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@windriver.com>
>> ---
>>   drivers/crypto/caam/caamalg_qi2.c | 31 ++++++++++++++++---------------
>>   drivers/crypto/caam/caamalg_qi2.h |  2 ++
>>   2 files changed, 18 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/crypto/caam/caamalg_qi2.c b/drivers/crypto/caam/caamalg_qi2.c
>> index 107ccb2ade42..a66c62174a0f 100644
>> --- a/drivers/crypto/caam/caamalg_qi2.c
>> +++ b/drivers/crypto/caam/caamalg_qi2.c
>> @@ -4810,6 +4810,17 @@ static void dpaa2_dpseci_congestion_free(struct dpaa2_caam_priv *priv)
>>        kfree(priv->cscn_mem);
>>   }
>>
>> +static void free_dpaa2_pcpu_netdev(struct dpaa2_caam_priv *priv, const cpumask_t *cpus)
>> +{
>> +     struct dpaa2_caam_priv_per_cpu *ppriv;
>> +     int i;
>> +
>> +     for_each_cpu(i, cpus) {
>> +             ppriv = per_cpu_ptr(priv->ppriv, i);
>> +             free_netdev(ppriv->net_dev);
>> +     }
>> +}
> 
> Why is the function being moved here? Please keep code movement separate
> from functional changes, or at minimum explain why the move is necessary
> in the commit message.
Thank you for the feedback.

I moved the function because I thought reusing existing code would be 
cleaner in dpaa2_dpseci_free. I will add the explain in commit message.

For future reference, what's the preferred approach when needing to 
reuse a simple function (4-line loop) defined later in the file - 
forward declaration, move it with a separate change or just implement 
directly?
Thanks for the guidance.

Regards,
Jianpeng


  reply	other threads:[~2026-01-16 10:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16  1:44 Jianpeng Chang
2026-01-16  8:19 ` kernel test robot
2026-01-16  9:05   ` Chang, Jianpeng (CN)
2026-01-16  9:46 ` Breno Leitao
2026-01-16 10:14   ` Chang, Jianpeng (CN) [this message]
2026-01-16 11:43     ` Breno Leitao
2026-01-19  2:02       ` Jianpeng Chang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a5b1ada-0602-4f43-b09b-ba1a8da26f21@windriver.com \
    --to=jianpeng.chang.cn@windriver.com \
    --cc=davem@davemloft.net \
    --cc=gaurav.jain@nxp.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@nxp.com \
    --cc=kuba@kernel.org \
    --cc=leitao@debian.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pankaj.gupta@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®