All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Atish Patra" <atish.patra@linux.dev>
Cc: conor+dt@kernel.org, linux-perf-users@vger.kernel.org,
	robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v8 15/22] RISC-V: perf: Skip PMU SBI extension when not implemented
Date: Wed, 01 Jul 2026 09:26:32 +0000	[thread overview]
Message-ID: <20260701092633.09F731F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701-counter_delegation-v8-15-7909f863a645@meta.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Skipping standard event checking when SBI is unavailable leaves event maps with valid default encodings, causing false-positive event support.
--

commit b28b4646a82db47f9cf2c2d617a8c7ae78dfb038
Author: Charlie Jenkins <charlie@rivosinc.com>

RISC-V: perf: Skip PMU SBI extension when not implemented

This commit modifies the RISC-V perf driver to skip the SBI extension for
counter configuration matching and firmware counter reads when the PMU
SBI extension is not implemented. It also prevents sbi_v2_available from
being set to true when the extension is missing.

> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
> --- a/drivers/perf/riscv_pmu_sbi.c
> +++ b/drivers/perf/riscv_pmu_sbi.c
> @@ -495,27 +495,32 @@ static void rvpmu_sbi_check_event(struct sbi_pmu_event_data *edata)
[ ... ]
> -static void rvpmu_sbi_check_std_events(struct work_struct *work)
> +static void rvpmu_check_std_events(struct work_struct *work)
>  {
>  	int ret;
>  
> -	if (sbi_v3_available) {
> -		ret = pmu_sbi_check_event_info();
> -		if (ret)
> -			pr_err("pmu_sbi_check_event_info failed with error %d\n", ret);
> -		return;
> -	}
> +	if (riscv_pmu_sbi_available()) {
> +		if (sbi_v3_available) {
> +			ret = pmu_sbi_check_event_info();
> +			if (ret)
> +				pr_err("pmu_sbi_check_event_info failed with error %d\n", ret);
> +			return;
> +		}
>  
> -	for (int i = 0; i < ARRAY_SIZE(pmu_hw_event_sbi_map); i++)
> -		rvpmu_sbi_check_event(&pmu_hw_event_sbi_map[i]);
> +		for (int i = 0; i < ARRAY_SIZE(pmu_hw_event_sbi_map); i++)
> +			rvpmu_sbi_check_event(&pmu_hw_event_sbi_map[i]);
>  
> -	for (int i = 0; i < ARRAY_SIZE(pmu_cache_event_sbi_map); i++)
> -		for (int j = 0; j < ARRAY_SIZE(pmu_cache_event_sbi_map[i]); j++)
> -			for (int k = 0; k < ARRAY_SIZE(pmu_cache_event_sbi_map[i][j]); k++)
> -				rvpmu_sbi_check_event(&pmu_cache_event_sbi_map[i][j][k]);
> +		for (int i = 0; i < ARRAY_SIZE(pmu_cache_event_sbi_map); i++)
> +			for (int j = 0; j < ARRAY_SIZE(pmu_cache_event_sbi_map[i]); j++)
> +				for (int k = 0; k < ARRAY_SIZE(pmu_cache_event_sbi_map[i][j]); k++)
> +					rvpmu_sbi_check_event(&pmu_cache_event_sbi_map[i][j][k]);
> +	} else {
> +		DO_ONCE_LITE_IF(1, pr_info,
> +				"Boot time config matching not required for smcdeleg\n");
> +	}
>  }

[Severity: High]
When riscv_pmu_sbi_available() is false, does skipping this loop leave the
event map arrays like pmu_hw_event_sbi_map with valid default event codes?

If these standard events are not invalidated via the hardware verification
step, riscv_pmu_get_event_info() could unconditionally return the default
uninvalidated values or synthesize valid encodings for firmware events.
Would this incorrectly signal to callers, such as KVM, that the events
are supported?

[ ... ]
> @@ -708,6 +713,9 @@ static int rvpmu_sbi_ctr_get_idx(struct perf_event *event)
>  
>  	cflags = rvpmu_sbi_get_filter_flags(event);
>  
> +	if (!riscv_pmu_sbi_available())
> +		return -ENOENT;

[Severity: High]
If firmware events successfully map via riscv_pmu_get_event_info() because
the mappings were left intact during initialization, they would be accepted
by perf_event_open. 

Will they then fail silently here at schedule time instead of being
appropriately rejected during event initialization?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701-counter_delegation-v8-0-7909f863a645@meta.com?part=15

  reply	other threads:[~2026-07-01  9:26 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01  8:46 [PATCH v8 00/22] Add Counter delegation ISA extension support Atish Patra
2026-07-01  8:46 ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 01/22] RISC-V: perf: fix resource cleanup on driver probe failure Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  9:11   ` sashiko-bot
2026-07-01  8:46 ` [PATCH v8 02/22] RISC-V: Add Sxcsrind ISA extension CSR definitions Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 03/22] RISC-V: Add Sxcsrind ISA extension definition and parsing Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 04/22] dt-bindings: riscv: add Sxcsrind ISA extension description Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 05/22] RISC-V: Define indirect CSR access helpers Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 06/22] RISC-V: Add Smcntrpmf extension parsing Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 07/22] dt-bindings: riscv: add Smcntrpmf ISA extension description Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 08/22] RISC-V: Add Sscfg extension CSR definition Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 09/22] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  9:11   ` sashiko-bot
2026-07-01  8:46 ` [PATCH v8 10/22] dt-bindings: riscv: add Counter delegation ISA extensions description Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:46 ` [PATCH v8 11/22] RISC-V: perf: Restructure the SBI PMU code Atish Patra
2026-07-01  8:46   ` Atish Patra
2026-07-01  8:47 ` [PATCH v8 12/22] RISC-V: perf: Modify the counter discovery mechanism Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  9:20   ` sashiko-bot
2026-07-07  7:45   ` Yicong Yang
2026-07-07  7:45     ` Yicong Yang
2026-07-01  8:47 ` [PATCH v8 13/22] RISC-V: perf: Add a mechanism to defined legacy event encoding Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  9:19   ` sashiko-bot
2026-07-07  7:51   ` Yicong Yang
2026-07-07  7:51     ` Yicong Yang
2026-07-01  8:47 ` [PATCH v8 14/22] RISC-V: perf: Implement supervisor counter delegation support Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  9:27   ` sashiko-bot
2026-07-07  8:24   ` Yicong Yang
2026-07-07  8:24     ` Yicong Yang
2026-07-01  8:47 ` [PATCH v8 15/22] RISC-V: perf: Skip PMU SBI extension when not implemented Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  9:26   ` sashiko-bot [this message]
2026-07-01  8:47 ` [PATCH v8 16/22] RISC-V: perf: Use config2/vendor table for event to counter mapping Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  9:35   ` sashiko-bot
2026-07-01  8:47 ` [PATCH v8 17/22] RISC-V: perf: Add legacy event encodings via sysfs Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  8:47 ` [PATCH v8 18/22] RISC-V: perf: Add Qemu virt machine events Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  8:47 ` [PATCH v8 19/22] tools/perf: Support event code for arch standard events Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01 17:44   ` Ian Rogers
2026-07-01 17:44     ` Ian Rogers
2026-07-01  8:47 ` [PATCH v8 20/22] tools/perf: Add RISC-V CounterIDMask event field Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01 17:44   ` Ian Rogers
2026-07-01 17:44     ` Ian Rogers
2026-07-01  8:47 ` [PATCH v8 21/22] TEST(do-not-upstream): fake qemu-virt PMU events for cdeleg counter-mask testing Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  9:38   ` sashiko-bot
2026-07-01  8:47 ` [PATCH v8 22/22] TEST(do-not-upstream): fake qemu vendor JSON + mapfile entry for CounterIDMask path Atish Patra
2026-07-01  8:47   ` Atish Patra
2026-07-01  9:34   ` 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=20260701092633.09F731F000E9@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 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.