mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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®