Re: [PATCH 05/21] perf: arm_pmuv3: Check cntr_mask before using pmccntr

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] A 64-bit user-access CPU_CYCLES event can bypass hardware width validation and be incorrectly mapped to a 32-bit general-purpose counter if armv8pmu_can_use_pmccntr() returns false.
--

commit d0aacbccd4b0e735717836a5d526ad70a89f9f39
Author: Colton Lewis <coltonlewis@google.com>

perf: arm_pmuv3: Check cntr_mask before using pmccntr

Check cntr_mask before using pmccntr to ensure it's available. With a
partitioned PMU, there may be instances where pmccntr is being used by
the guest and will be absent from cntr_mask.

> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index 1cceb1f614515..17bb1cfdc271c 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -1028,7 +1028,8 @@ static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
>  
>  	/* Always prefer to place a cycle counter into the cycle counter. */
>  	if (armv8pmu_can_use_pmccntr(cpuc, event)) {
> -		if (!test_and_set_bit(ARMV8_PMU_CYCLE_IDX, cpuc->used_mask))
> +		if (test_bit(ARMV8_PMU_CYCLE_IDX, cpu_pmu->cntr_mask) &&
> +		    !test_and_set_bit(ARMV8_PMU_CYCLE_IDX, cpuc->used_mask))
>  			return ARMV8_PMU_CYCLE_IDX;
>  		else if (armv8pmu_event_is_64bit(event) &&
>  			   armv8pmu_event_want_user_access(event) &&

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for a 64-bit
user-access CPU_CYCLES event to bypass hardware width validation here?

Because the -EAGAIN rejection logic is nested inside the 
armv8pmu_can_use_pmccntr() check, if that function returns false (for example,
if threshold counting is enabled or the system has SMT), this validation is
entirely skipped.

It looks like the event would then fall through to armv8pmu_get_single_idx()
and potentially be allocated a 32-bit general-purpose counter. Userspace perf
tools reading the userpage pmc_width as 64 would then treat a 32-bit counter
as 64-bit, leading to unhandled wraparounds.

Looking at __armv8_pmuv3_map_event(), CPU_CYCLES events are explicitly
exempted from the 64-bit unsupported check:

__armv8_pmuv3_map_event()
        if (armv8pmu_event_is_64bit(event) &&
            (hw_event_id != ARMV8_PMUV3_PERFCTR_CPU_CYCLES) &&
            !armv8pmu_has_long_event(armpmu))
                return -EOPNOTSUPP;

Does this code incorrectly map 64-bit CPU_CYCLES events to 32-bit counters
when the dedicated 64-bit PMCCNTR is unavailable?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612192909.1153907-1-coltonlewis@google.com?part=5