Re: [PATCH] crypto: caam: fix netdev memory leak in dpaa2_caam_probe

[Jianpeng Chang <jianpeng.chang.cn@windriver.com>]

在 2026/1/16 下午7:43, Breno Leitao 写道:
> 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.
> 
> Hello Jianpeng,
> 
> On Fri, Jan 16, 2026 at 06:14:37PM +0800, Chang, Jianpeng (CN) wrote:
>> 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)
>>> c> +{
>>>> +     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?
> 
> It is fine to implement directly, but, I am a bit confused with the
> solution, let me back up a bit.
> 
> First, it seems the problem is real and thanks for fixing it.
> 
> Regarding the solution, I am wondering if it is not simpler to iterate
> the priv->num_pairs and kfreeing them in dpaa2_dpseci_free(), similarly
> to dpaa2_dpseci_disable().
Hi Leitao,

Thanks for you reply, I will implement directly instead of moving the 
function in v2.

I have considered using the approach of iterating through 
priv->num_pairs, but the index of num_pairs cannot represent the CPU number.

Consider a theoretical scenario where there are multiple CPUs and the 
cpu 2 is disabled. When iterating through num_pairs, we would get 
per_cpu_ptr(priv->ppriv, 2), but this would be meaningless.

This is not a critical issue, and I don't have a strong preference 
either way. I just think using a CPU mask to ensure precise cleanup 
might be more appropriate.
Furthermore, there are risks in using num_pairs. If we manually disable 
a CPU and then disable/enable the driver, we would encounter an oops, 
but that's a separate issue.

Thanks,
Jianpeng