From: Edward Cree <ecree.xilinx@gmail.com>
To: Jacob Keller <jacob.e.keller@intel.com>,
Abdun Nihaal <nihaal@cse.iitm.ac.in>
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, habetsm.xilinx@gmail.com,
alejandro.lucero-palau@amd.com, netdev@vger.kernel.org,
linux-net-drivers@amd.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net] sfc: fix potential memory leak in efx_mae_process_mport()
Date: Fri, 24 Oct 2025 15:48:44 +0100 [thread overview]
Message-ID: <699aa920-ac7a-43ef-8ad5-5157d0018b54@gmail.com> (raw)
In-Reply-To: <a4ef697b-74f4-4a47-ac0b-30608b204a4c@intel.com>
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.
next prev parent reply other threads:[~2025-10-24 14:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 14:18 Abdun Nihaal
2025-10-24 0:48 ` Jacob Keller
2025-10-24 14:36 ` Abdun Nihaal
2025-10-24 14:48 ` Edward Cree [this message]
2025-10-24 20:13 ` Jacob Keller
2025-10-28 1:00 ` patchwork-bot+netdevbpf
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=699aa920-ac7a-43ef-8ad5-5157d0018b54@gmail.com \
--to=ecree.xilinx@gmail.com \
--cc=alejandro.lucero-palau@amd.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=habetsm.xilinx@gmail.com \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net-drivers@amd.com \
--cc=netdev@vger.kernel.org \
--cc=nihaal@cse.iitm.ac.in \
--cc=pabeni@redhat.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®