linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Mukesh Kumar Chaurasiya <mchauras@linux.ibm.com>
Cc: Athira Rajeev <atrajeev@linux.ibm.com>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ian Rogers <irogers@google.com>,
	"open list:PERFORMANCE EVENTS SUBSYSTEM"
	<linux-perf-users@vger.kernel.org>,
	Likhitha Korrapati <likhitha@linux.ibm.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>
Subject: Re: [PATCH] tools/lib/perf: Fix -Werror=alloc-size-larger-than in cpumap.c
Date: Tue, 13 May 2025 18:13:11 -0300	[thread overview]
Message-ID: <aCO156Qh5mbeR4Sk@x1> (raw)
In-Reply-To: <wqewmdha3bx7pmxqwbna26qnl55fcejqsjs4b2zhuciddpb3b5@7ztolpf6erwo>

On Fri, May 02, 2025 at 01:14:32PM +0530, Mukesh Kumar Chaurasiya wrote:
> On Fri, Apr 25, 2025 at 02:46:43PM -0300, Arnaldo Carvalho de Melo wrote:
> > Maybe that max() call in perf_cpu_map__intersect() somehow makes the
> > compiler happy.

> > And in perf_cpu_map__alloc() all calls seems to validate it.
 
> > Like:

> > +++ b/tools/lib/perf/cpumap.c
> > @@ -411,7 +411,7 @@ int perf_cpu_map__merge(struct perf_cpu_map **orig, struct perf_cpu_map *other)
> >         }
> >  
> >         tmp_len = __perf_cpu_map__nr(*orig) + __perf_cpu_map__nr(other);
> > -       tmp_cpus = malloc(tmp_len * sizeof(struct perf_cpu));
> > +       tmp_cpus = calloc(tmp_len, sizeof(struct perf_cpu));
> >         if (!tmp_cpus)
> >                 return -ENOMEM;

> > ⬢ [acme@toolbx perf-tools-next]$

> > And better, do the max size that the compiler is trying to help us
> > catch?

> Isn't it better to use perf_cpu_map__nr. That should fix this problem.

Maybe, have you tried it?
 
> One question I have, in perf_cpu_map__nr, the function is returning
> 1 in case *cpus is NULL. Is it ok to do that? wouldn't it cause problems?

Indeed this better be documented, as by just looking at:

int perf_cpu_map__nr(const struct perf_cpu_map *cpus)
{
        return cpus ? __perf_cpu_map__nr(cpus) : 1;
}

It really doesn't make much sense to say that a NULL map has one entry.

But the next functions are:

bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
{
        return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
}

bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
{
        if (!map)
                return true;

        return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
}

bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
{
        return map == NULL;
}

So it seems that a NULL cpu map means "any/all CPU) and a map with just
one entry would have as its content "-1" that would mean "any/all CPU".

Ian did work on trying to simplify/clarify this, so maybe he can chime
in :-)

- Arnaldo

  reply	other threads:[~2025-05-13 21:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-06 16:34 [PATCH] tools/lib/perf: Fix -Werror=alloc-size-larger-than in cpumap.c Likhitha Korrapati
2025-04-06 18:40 ` Athira Rajeev
2025-04-07 12:08   ` Venkat Rao Bagalkote
2025-04-14  1:38     ` Madhavan Srinivasan
2025-04-25 14:49       ` Athira Rajeev
2025-04-25 17:46         ` Arnaldo Carvalho de Melo
2025-04-29  5:11           ` Likhitha Korrapati
2025-05-02  7:44           ` Mukesh Kumar Chaurasiya
2025-05-13 21:13             ` Arnaldo Carvalho de Melo [this message]
2025-05-13 22:12               ` Ian Rogers
2025-05-13 22:36                 ` Ian Rogers
2025-05-21 13:03               ` Likhitha Korrapati
2025-05-21 15:45                 ` Ian Rogers
2025-05-21 17:28                   ` Likhitha Korrapati
2025-05-21 17:39                     ` Ian Rogers
2025-05-02  9:05           ` Likhitha Korrapati
2025-04-07  5:39 ` Mukesh Kumar Chaurasiya

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=aCO156Qh5mbeR4Sk@x1 \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=atrajeev@linux.ibm.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=likhitha@linux.ibm.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mchauras@linux.ibm.com \
    --cc=namhyung@kernel.org \
    --cc=venkat88@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).