All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] tools/lib/api: Check nonfilterable in fdarray__filter()
Date: Fri, 10 Jul 2026 14:51:11 -0700	[thread overview]
Message-ID: <alFpTwZSuYR6eh0u@google.com> (raw)
In-Reply-To: <20260710200150.11FE71F00A3A@smtp.kernel.org>

On Fri, Jul 10, 2026 at 08:01:49PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] If `realloc` for `fda->priv` fails in `fdarray__grow()`, a dangling pointer is left in `fda->entries`, leading to a double-free during error cleanup.
> --
> 
> --- Patch [1]: [PATCH] tools/lib/api: Check nonfilterable in fdarray__filter() ---
> commit f87f1b3c291ca03e96598f96697566a328711de3
> Author: Namhyung Kim <namhyung@kernel.org>
> 
>     tools/lib/api: Check nonfilterable in fdarray__filter()
>     
>     IIUC fdarray__filter() should check filterable events only and leave
>     non-filterable events to be handled outside.  The recent change to set
>     fd to -1 made perf record test stuck forever.  Adding the check the flag
>     fixes the problem for me.
> 
> > diff --git a/tools/lib/api/fd/array.c b/tools/lib/api/fd/array.c
> > index ffe8272af59b2..b4570e4981492 100644
> > --- a/tools/lib/api/fd/array.c
> > +++ b/tools/lib/api/fd/array.c
> > @@ -117,6 +117,8 @@ int fdarray__filter(struct fdarray *fda, short revents,
> >  	for (fd = 0; fd < fda->nr; ++fd) {
> >  		if (!fda->entries[fd].events)
> >  			continue;
> > +		if (fda->priv[fd].flags & fdarray_flag__nonfilterable)
> > +			continue;
> 
> [Severity: High]
> This is a pre-existing issue, but while looking at this file I noticed a
> potential double-free in fdarray__grow() during error handling.

I'll handle this in a separate patch.

Thanks,
Namhyung

> 
> If the realloc for fda->entries succeeds but the realloc for fda->priv
> fails, the error path frees the newly allocated entries:
> 
> tools/lib/api/fd/array.c:fdarray__grow() {
>     ...
> 	struct pollfd *entries = realloc(fda->entries, size);
> 
> 	if (entries == NULL)
> 		return -ENOMEM;
> 
> 	priv = realloc(fda->priv, psize);
> 	if (priv == NULL) {
> 		free(entries);
> 		return -ENOMEM;
> 	}
>     ...
> }
> 
> However, fda->entries is neither updated to point to the new entries block
> nor cleared to NULL. If realloc moved the allocation to a new block, the
> old fda->entries pointer is now freed memory.
> 
> When fdarray__exit() is later called to clean up, it executes
> free(fda->entries), which would trigger a double-free on that old pointer.
> 
> Would it be better to clear fda->entries to NULL here, or avoid modifying
> the struct state until both allocations succeed?
> 
> [ ... ]
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260710194222.1788638-1-namhyung@kernel.org?part=1

      reply	other threads:[~2026-07-10 21:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 19:42 [PATCH] tools/lib/api: Check nonfilterable in fdarray__filter() Namhyung Kim
2026-07-10 20:01 ` sashiko-bot
2026-07-10 21:51   ` Namhyung Kim [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=alFpTwZSuYR6eh0u@google.com \
    --to=namhyung@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.