[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <699aa920-ac7a-43ef-8ad5-5157d0018b54@gmail.com>
Date: Fri, 24 Oct 2025 15:48:44 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Jacob Keller <jacob.e.keller@...el.com>,
Abdun Nihaal <nihaal@....iitm.ac.in>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, habetsm.xilinx@...il.com,
alejandro.lucero-palau@....com, netdev@...r.kernel.org,
linux-net-drivers@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 net] sfc: fix potential memory leak in
efx_mae_process_mport()
On 24/10/2025 01:48, Jacob Keller wrote:
> On 10/23/2025 7:18 AM, Abdun Nihaal wrote:
>> In efx_mae_enumerate_mports(), memory allocated for mae_mport_desc is
>> passed as a argument to efx_mae_process_mport(), but when the error path
>> in efx_mae_process_mport() gets executed, the memory allocated for desc
>> gets leaked.
>>
>> Fix that by freeing the memory allocation before returning error.
>
> Why not make the caller responsible for freeing desc on failure?
Since the callee takes ownership of desc on success (it stashes it in a
table), arguably it's cleaner to have it do so in all cases; it's an
aesthetic judgment call but I think I'd rather keep it this way and just
fix this one failure path than change all the existing failure paths and
the caller.
Alejandro (original author of this code) might have a different opinion
in which case I'll defer to him but otherwise I'd say v2 is fine to apply
as-is.
Powered by blists - more mailing lists