linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: LuMingYin <lumingyindetect@163.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org
Subject: Re: [PATCH] tools:Fix a memory leak related to variable name
Date: Sat, 23 Mar 2024 11:22:09 -0700	[thread overview]
Message-ID: <20240323182209.xqzb6rsswvfbg74n@treble> (raw)
In-Reply-To: <20240323084526.662556-1-lumingyindetect@163.com>

On Sat, Mar 23, 2024 at 04:45:26PM +0800, LuMingYin wrote:
> In the elf_create_prefix_symbol function defined in the /linux/tools/objtool/elf.c file, two pointer variables sym and name are defined. The program allocates dynamic memory for the pointer sym using the calloc function at line 822, and for the pointer name using the malloc function at line 824. When the if statement at line 826 returns true, the program returns at line 828. The content of the if statement at line 828 is if (sym==NULL || name==NULL), which checks if either sym or name is NULL. If this condition returns true, it indicates a situation where one of the pointers has successfully allocated memory but the other has not. Therefore, if the if statement returns true, directly returning may lead to memory leak issues. Hence, in the code, I have added checks separately for whether sym and name are NULL, and if they are not NULL, the corresponding dynamic memory spaces are freed.
> 
> Signed-off-by: LuMingYin <lumingyindetect@163.com>

Thanks for the patch.  In general we don't care about memory leaks in
objtool (particularly in error or exit paths), as it's a short-running
tool.  When it exits, all the memory will be freed anyway.  So it's
faster to not free the memory manually.

-- 
Josh

  reply	other threads:[~2024-03-23 18:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-23  8:45 [PATCH] tools:Fix a memory leak related to variable name LuMingYin
2024-03-23 18:22 ` Josh Poimboeuf [this message]
2024-03-24  5:56   ` lumingyindetect
2024-03-24  5:59   ` lumingyindetect

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=20240323182209.xqzb6rsswvfbg74n@treble \
    --to=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lumingyindetect@163.com \
    --cc=peterz@infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).