Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Atish Patra" <atish.patra@linux.dev>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
	linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v7 19/22] tools/perf: Support event code for arch standard events
Date: Mon, 22 Jun 2026 08:34:33 +0000	[thread overview]
Message-ID: <20260622083434.2DA181F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260622-counter_delegation-v7-19-0ba2fd34614e@meta.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Logic error in preserving event encodings for architecture standard events: the script silently discards valid `EventCode: 0`, alternate encodings (e.g., `ConfigCode`), and all associated modifiers (e.g., `UMask`, `CounterIDMask`).
--

commit 49dcf2f5443f8355e35a6c0465204600a8115b63
Author: Atish Patra <atishp@rivosinc.com>

tools/perf: Support event code for arch standard events

This commit modifies the perf tool's json event parsing to preserve the event
encoding of architecture standard events. It skips overwriting the event code
if one is already provided in the json file.

> diff --git a/tools/perf/pmu-events/jevents.py b/tools/perf/pmu-events/jevents.py
> index 3a1bcdcdc685f..457fce7a59820 100755
> --- a/tools/perf/pmu-events/jevents.py
> +++ b/tools/perf/pmu-events/jevents.py
> @@ -413,7 +413,11 @@ class JsonEvent:
>          self.long_desc = None
>      if arch_std:
>        if arch_std.lower() in _arch_std_events:
> -        event = _arch_std_events[arch_std.lower()].event
> +        # If the JSON event already specified an event code, the encoding has
> +        # been set above; don't overwrite it with the arch standard event or
> +        # the event encoding would be lost.
> +        if not eventcode:
> +          event = _arch_std_events[arch_std.lower()].event

[Severity: High]
Does this check properly handle an event code of 0 or alternate encodings?

If EventCode is explicitly 0, or if an alternate encoding like ConfigCode
is used (leaving eventcode as 0), the truthiness check will evaluate to true.

This would cause JsonEvent.__init__ to overwrite the newly constructed event
string with the base architecture standard event string, silently discarding
the explicit 0 encoding or alternate encodings, as well as any modifiers
appended beforehand like UMask.

Would it be safer to check dictionary membership directly, or initialize
eventcode to None to distinguish between an explicit 0 and an unset value?

>          # Copy from the architecture standard event to self for undefined fields.
>          for attr, value in _arch_std_events[arch_std.lower()].__dict__.items():
>            if hasattr(self, attr) and not getattr(self, attr):

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com?part=19

  reply	other threads:[~2026-06-22  8:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22  8:04 [PATCH v7 00/22] Add Counter delegation ISA extension support Atish Patra
2026-06-22  8:04 ` [PATCH v7 01/22] RISC-V: perf: fix resource cleanup on driver probe failure Atish Patra
2026-06-22  8:24   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 02/22] RISC-V: Add Sxcsrind ISA extension CSR definitions Atish Patra
2026-06-22  8:04 ` [PATCH v7 03/22] RISC-V: Add Sxcsrind ISA extension definition and parsing Atish Patra
2026-06-22  8:04 ` [PATCH v7 04/22] dt-bindings: riscv: add Sxcsrind ISA extension description Atish Patra
2026-06-22  8:04 ` [PATCH v7 05/22] RISC-V: Define indirect CSR access helpers Atish Patra
2026-06-22  8:17   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 06/22] RISC-V: Add Smcntrpmf extension parsing Atish Patra
2026-06-22  8:17   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 07/22] dt-bindings: riscv: add Smcntrpmf ISA extension description Atish Patra
2026-06-22  8:04 ` [PATCH v7 08/22] RISC-V: Add Sscfg extension CSR definition Atish Patra
2026-06-22  8:04 ` [PATCH v7 09/22] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing Atish Patra
2026-06-22  8:18   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 10/22] dt-bindings: riscv: add Counter delegation ISA extensions description Atish Patra
2026-06-22  8:20   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 11/22] RISC-V: perf: Restructure the SBI PMU code Atish Patra
2026-06-22  8:04 ` [PATCH v7 12/22] RISC-V: perf: Modify the counter discovery mechanism Atish Patra
2026-06-22  8:24   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 13/22] RISC-V: perf: Add a mechanism to defined legacy event encoding Atish Patra
2026-06-22  8:04 ` [PATCH v7 14/22] RISC-V: perf: Implement supervisor counter delegation support Atish Patra
2026-06-22  8:33   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 15/22] RISC-V: perf: Skip PMU SBI extension when not implemented Atish Patra
2026-06-22  8:04 ` [PATCH v7 16/22] RISC-V: perf: Use config2/vendor table for event to counter mapping Atish Patra
2026-06-22  8:30   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 17/22] RISC-V: perf: Add legacy event encodings via sysfs Atish Patra
2026-06-22  8:04 ` [PATCH v7 18/22] RISC-V: perf: Add Qemu virt machine events Atish Patra
2026-06-22  8:39   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 19/22] tools/perf: Support event code for arch standard events Atish Patra
2026-06-22  8:34   ` sashiko-bot [this message]
2026-06-22  8:04 ` [PATCH v7 20/22] tools/perf: Add RISC-V CounterIDMask event field Atish Patra
2026-06-22  8:04 ` [PATCH v7 21/22] TEST(do-not-upstream): fake qemu-virt PMU events for cdeleg counter-mask testing Atish Patra
2026-06-22  8:32   ` sashiko-bot
2026-06-22  8:04 ` [PATCH v7 22/22] TEST(do-not-upstream): fake qemu vendor JSON + mapfile entry for CounterIDMask path Atish Patra
2026-06-22  8:35   ` 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=20260622083434.2DA181F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atish.patra@linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox