All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vishal Moola <vishal.moola@gmail.com>
To: Yichong Chen <chenyichong@uniontech.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v2] tools/mm/page_owner_sort: free per-record allocations
Date: Thu, 11 Jun 2026 12:50:52 +0100	[thread overview]
Message-ID: <aiqhHE9uROfs_4p9@fedora> (raw)
In-Reply-To: <aipzJR0KnO76crLy@fedora>

On Thu, Jun 11, 2026 at 09:34:45AM +0100, Vishal Moola wrote:
> On Thu, Jun 11, 2026 at 10:34:11AM +0800, Yichong Chen wrote:
> > add_list() allocates comm and txt for each page owner record, but the
> > cleanup path only frees the outer list array. This leaks both buffers for
> > every retained record.
> > 
> > Free discarded records during culling and free the retained records on
> > exit. Also unwind comm when allocating txt fails.
> > 
> > Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
> > ---
> > Changes in v2:
> > - Wrap commit message lines to approximately 75 columns.
> > - Use "Yichong Chen" as the author name.
> 
> Thanks. Also, in the future send new versions as new threads :)
> 
> The patch looks fine, just see below for my comment you might have
> missed last time.

Sashiko also caught that is_need() calls get_comm(). That looks like it
should be handling the NULL return case as well. It appears to be an
existing issue, but it could fit into this patch if respinning for v3.

> > @@ -480,9 +489,15 @@ static bool add_list(char *buf, int len, char *ext_buf)
> >  	list[list_size].pid = get_pid(buf);
> >  	list[list_size].tgid = get_tgid(buf);
> >  	list[list_size].comm = get_comm(buf);
> > +	if (!list[list_size].comm) {
> > +		fprintf(stderr, "Out of memory\n");
> > +		return false;
> > +	}
> >  	list[list_size].txt = malloc(len+1);
> >  	if (!list[list_size].txt) {
> >  		fprintf(stderr, "Out of memory\n");
> > +		free(list[list_size].comm);
> > +		list[list_size].comm = NULL;
> >  		return false;
> 
> Returning false here sends us back to the error handling path in main()
> where you end up calling your free_block_list() anyway. So we don't need
> this here, right?
> 
> >  	}
> >  	memcpy(list[list_size].txt, buf, len);
> 


      reply	other threads:[~2026-06-11 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-10  2:11 [PATCH] tools/mm/page_owner_sort: free per-record allocations chenyichong
2026-06-10 10:46 ` Vishal Moola
2026-06-11  2:34   ` [PATCH v2] " Yichong Chen
2026-06-11  8:34     ` Vishal Moola
2026-06-11 11:50       ` Vishal Moola [this message]

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=aiqhHE9uROfs_4p9@fedora \
    --to=vishal.moola@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chenyichong@uniontech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.