From: sashiko-bot@kernel.org
To: "Athira Rajeev" <atrajeev@linux.ibm.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V2 4/6] tools/perf: Add powerpc callback support for arch_perf_record__need_read
Date: Mon, 20 Jul 2026 11:18:24 +0000 [thread overview]
Message-ID: <20260720111824.E37591F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260720105218.14277-5-atrajeev@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The function identifies HTM events using a highly brittle prefix match on the event name (`strstarts(evsel->name, "htm")`), which will erroneously match unrelated user-named events or tracepoints.
- [Low] The file uses `strcmp()` and `bool` but fails to explicitly include the standard POSIX headers `<string.h>` and `<stdbool.h>`, violating the subsystem musl compatibility guidelines.
- [Low] The string comparison against 'dummy:u' is mathematically unreachable and constitutes dead code.
--
--- Patch [4]: [PATCH V2 4/6] tools/perf: Add powerpc callback support for arch_perf_record__need_read ---
commit 08efcd22d3e33aa6575dbd818f05eb3b46a80a92
Author: Athira Rajeev <atrajeev@linux.ibm.com>
tools/perf: Add powerpc callback support for arch_perf_record__need_read
Implement the arch_perf_record__need_read() architecture-specific hook
for powerpc in arch/powerpc/util/evsel.c. The hook reads event counts for
open htm evsels to determine if data is pending.
> diff --git a/tools/perf/arch/powerpc/util/evsel.c b/tools/perf/arch/powerpc/util/evsel.c
> index 2f733cdc8dbbe..8f2805a680261 100644
> --- a/tools/perf/arch/powerpc/util/evsel.c
> +++ b/tools/perf/arch/powerpc/util/evsel.c
> @@ -1,8 +1,77 @@
> // SPDX-License-Identifier: GPL-2.0
> #include <stdio.h>
> +#include <linux/string.h>
> #include "util/evsel.h"
> +#include "util/record.h"
> +#include "util/evlist.h"
> +#include "util/debug.h"
> +#include <internal/xyarray.h>
[Severity: Low]
Does this file need to explicitly include <string.h> and <stdbool.h>?
This file uses bool and strcmp(), but relies on implicit inclusion or
<linux/string.h>. Compiling perf against musl libc requires direct inclusion
of standard POSIX headers for these types and functions to avoid build
failures.
[ ... ]
> +int arch_perf_record__need_read(struct evlist *evlist)
> +{
> + struct evsel *evsel;
[ ... ]
> + /* Read HTM event counts to check if more data is available */
> + evlist__for_each_entry(evlist, evsel) {
> + struct xyarray *xy = evsel->core.sample_id;
> +
> + if (!evsel->name || !strstarts(evsel->name, "htm"))
> + continue;
[Severity: Medium]
Is it safe to identify HTM events using a prefix match on the event name?
If a user traces a standard event and names it with an "htm" prefix (e.g.,
perf record -e cpu-cycles/name=htm_cycles/), this hook would falsely
identify it as an HTM event and read its event count.
For standard events, this count contains the actual accumulated hits, not the
0/1 driver staging flag, causing total_pending_bytes to always be > 0. Would
this force arch_perf_record__need_read() to always return 1 and cause the
drain loop in record__final_data() to instantly abort with a spurious warning
about making no forward progress?
Would it be more robust to identify these events by checking the PMU type
instead of the name?
> +
> + if (!strcmp(evsel->name, "dummy:u"))
> + continue;
[Severity: Low]
Is this string comparison reachable?
The loop explicitly filters events above with:
if (!evsel->name || !strstarts(evsel->name, "htm")) continue;
Because "dummy:u" does not start with "htm", any "dummy:u" event is already
caught and skipped by the first condition, making this check dead code.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720105218.14277-1-atrajeev@linux.ibm.com?part=4
next prev parent reply other threads:[~2026-07-20 11:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 10:52 [PATCH V2 0/6] tools/perf: Add powerpc HTM auxtrace support Athira Rajeev
2026-07-20 10:52 ` [PATCH V2 1/6] tools/perf: Move powerpc VPA-DTL auxtrace init into a separate file Athira Rajeev
2026-07-20 11:15 ` sashiko-bot
2026-07-20 10:52 ` [PATCH V2 2/6] tools/perf: Add AUXTRACE recording support for powerpc HTM Athira Rajeev
2026-07-20 11:20 ` sashiko-bot
2026-07-20 10:52 ` [PATCH V2 3/6] tools/perf: Add arch hook to drain remaining data before event close Athira Rajeev
2026-07-20 11:16 ` sashiko-bot
2026-07-20 10:52 ` [PATCH V2 4/6] tools/perf: Add powerpc callback support for arch_perf_record__need_read Athira Rajeev
2026-07-20 11:18 ` sashiko-bot [this message]
2026-07-20 10:52 ` [PATCH V2 5/6] tools/perf: Add powerpc HTM auxtrace event processing support Athira Rajeev
2026-07-20 11:18 ` sashiko-bot
2026-07-20 10:52 ` [PATCH V2 6/6] tools/perf: Add perf tool support for processing powerpc HTM AUXTRACE records Athira Rajeev
2026-07-20 11:25 ` sashiko-bot
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=20260720111824.E37591F00A3A@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.