All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Athira Rajeev" <atrajeev@linux.ibm.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V5 2/6] tools/perf: Add AUXTRACE recording support for powerpc HTM
Date: Fri, 07 Aug 2026 14:59:57 +0000	[thread overview]
Message-ID: <20260807145958.2AEF21F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260807144135.2607-3-atrajeev@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Heap buffer overflow in htm_info_fill() due to undersized PERF_RECORD_AUXTRACE_INFO allocation for HTM evsels covering multiple CPUs.
- [Low] Missing explicit inclusion of `<string.h>` for `strcmp()`, violating musl libc compatibility guidelines.
--

--- Patch [2]: [PATCH V5 2/6] tools/perf: Add AUXTRACE recording support for powerpc HTM ---
commit 36cc90227b9052ae32b72e6b7df67e4e6bc7ac1e
Author: Athira Rajeev <atrajeev@linux.ibm.com>

tools/perf: Add AUXTRACE recording support for powerpc HTM

Add powerpc perf tool support for the HTM PMU AUXTRACE recording path.
Introduce htm_recording_init() and the associated auxtrace callbacks so
perf record can create PERF_RECORD_AUXTRACE records for HTM data.

> diff --git a/tools/perf/arch/powerpc/util/htm.c b/tools/perf/arch/powerpc/util/htm.c
> new file mode 100644
> index 0000000000000..d2fdef4880320
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/htm.c
> @@ -0,0 +1,185 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * HTM AUX tracing support
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/string.h>
> +#include <linux/zalloc.h>

[Severity: Low]
This isn't a bug, but this file uses strcmp() which is declared in <string.h>.
Does this code need to explicitly include <string.h> to avoid relying on
implicit inclusion, which might cause build failures in strictly conformant
musl libc environments?

[ ... ]

> +/* Count htm evsels in the evlist */
> +static int htm_nr_events(struct evlist *evlist)
> +{
> +	struct evsel *pos;
> +	int n = 0;
> +
> +	evlist__for_each_entry(evlist, pos) {
> +		if (!strcmp(evsel__pmu_name(pos), "htm"))
> +			n++;
> +	}
> +	return n;
> +}
> +
> +static size_t htm_info_priv_size(struct auxtrace_record *itr __maybe_unused,
> +				 struct evlist *evlist)
> +{
> +	return HTM_AUXTRACE_PRIV_SIZE(htm_nr_events(evlist));
> +}

[ ... ]

> +/*
> + * Fill the PERF_RECORD_AUXTRACE_INFO private data with:
> + *   priv[POWERPC_HTM_PMU_TYPE]   = pmu->type of the first htm evsel
> + *   priv[POWERPC_HTM_NUM_EVENTS] = total number of HTM CPU entries
> + *   priv[POWERPC_HTM_EVENT_DATA + n*2]     = CPU number for nth entry
> + *   priv[POWERPC_HTM_EVENT_DATA + n*2 + 1] = attr.config for nth entry
> + *
> + * One entry is written per CPU in each evsel's cpu map.  An evsel opened
> + * with -C 0,1,2 contributes three entries (one per CPU), each carrying
> + * the same attr.config.  The decode side uses event->auxtrace.cpu to look
> + * up the matching config and derive (node, chip, core) for the output
> + * file name.
> + */
> +static int
> +htm_info_fill(struct auxtrace_record *itr,
> +	      struct perf_session *session,
> +	      struct perf_record_auxtrace_info *auxtrace_info,
> +	      size_t priv_size)
> +{
> +	struct htm_recording *htm_r = container_of(itr, struct htm_recording, itr);
> +	struct evlist *evlist = session->evlist;
> +	struct evsel *pos;
> +	int n = 0;
> +	int expected_n = htm_nr_events(evlist);
> +
> +	if (priv_size != HTM_AUXTRACE_PRIV_SIZE(expected_n))
> +		return -EINVAL;
> +
> +	auxtrace_info->type = PERF_AUXTRACE_POWERPC_HTM;
> +	auxtrace_info->priv[POWERPC_HTM_PMU_TYPE] = htm_r->evsel->core.attr.type;
> +	auxtrace_info->priv[POWERPC_HTM_NUM_EVENTS] = expected_n;
> +
> +	evlist__for_each_entry(evlist, pos) {
> +		struct perf_cpu_map *cpus;
> +		int i, nr;
> +
> +		if (strcmp(evsel__pmu_name(pos), "htm"))
> +			continue;
> +
> +		/*
> +		 * Emit one (cpu, config) entry for every CPU in this evsel's
> +		 * map.  perf record -C 0,1,2 creates one evsel with a
> +		 * three-entry cpu map; each CPU gets its own AUX buffer and
> +		 * must be individually mapped so the decoder can match
> +		 * event->auxtrace.cpu to the correct (node, chip, core).
> +		 */
> +		cpus = evsel__cpus(pos);
> +		nr = cpus ? perf_cpu_map__nr(cpus) : 0;
> +
> +		if (nr > 0) {
> +			for (i = 0; i < nr; i++) {
> +				int cpu = perf_cpu_map__cpu(cpus, i).cpu;
> +
> +				auxtrace_info->priv[POWERPC_HTM_EVENT_DATA + n * 2]     = cpu;
> +				auxtrace_info->priv[POWERPC_HTM_EVENT_DATA + n * 2 + 1] =
> +								pos->core.attr.config;
> +				n++;

[Severity: High]
Does this code overflow the auxtrace_info->priv[] array when an HTM evsel
covers multiple CPUs?

The auxtrace_info->priv[] buffer size is calculated by htm_nr_events() above,
which only counts the total number of HTM evsels. If a user runs perf record
with a CPU list (e.g., -C 0,1,2), there might be only 1 evsel, resulting in
space allocated for a single (cpu, config) pair.

However, this loop iterates over the CPU map and writes a pair for every CPU
in that evsel (e.g., 3 CPUs), incrementing n past the allocated size.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807144135.2607-1-atrajeev@linux.ibm.com?part=2

  reply	other threads:[~2026-08-07 14:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 14:41 [PATCH V5 0/6] tools/perf: Add powerpc HTM auxtrace support Athira Rajeev
2026-08-07 14:41 ` [PATCH V5 1/6] tools/perf: Move powerpc VPA-DTL auxtrace init into a separate file Athira Rajeev
2026-08-07 14:41 ` [PATCH V5 2/6] tools/perf: Add AUXTRACE recording support for powerpc HTM Athira Rajeev
2026-08-07 14:59   ` sashiko-bot [this message]
2026-08-08  3:50     ` Athira Rajeev
2026-08-07 14:41 ` [PATCH V5 3/6] tools/perf: Add arch hook to drain remaining data before event close Athira Rajeev
2026-08-07 15:20   ` sashiko-bot
2026-08-08  4:05     ` Athira Rajeev
2026-08-07 14:41 ` [PATCH V5 4/6] tools/perf: Add powerpc callback support for arch_perf_record__need_read Athira Rajeev
2026-08-07 15:32   ` sashiko-bot
2026-08-07 14:41 ` [PATCH V5 5/6] tools/perf: Add powerpc HTM auxtrace event processing support Athira Rajeev
2026-08-07 15:33   ` sashiko-bot
2026-08-08  4:09     ` Athira Rajeev
2026-08-07 14:41 ` [PATCH V5 6/6] tools/perf: Add perf tool support for processing powerpc HTM AUXTRACE records Athira Rajeev
2026-08-08  5:11 ` [PATCH V5 0/6] tools/perf: Add powerpc HTM auxtrace support Athira Rajeev

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=20260807145958.2AEF21F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atrajeev@linux.ibm.com \
    --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.