Re: [PATCH v1 30/41] perf pmu: Probe precise_ip levels

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf pmu: false precise_ip levels for sampling-only PMUs in __perf_pmu__probe()
--

commit d1ce0d9ed1dbce5cef4c6ec1524e970638e08a49
Author: Ian Rogers <irogers@google.com>

perf pmu: Probe precise_ip levels

This commit extends perf_pmu__probe() to probe supported precise_ip
levels (1..3) and populate probed.precise_mask and probed.max_precise.
To avoid misreporting non-precise PMUs that silently ignore precise_ip,
it checks whether precise_ip = 1 succeeds on a counting event when
pmu->probed.can_count is true.

> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 164ed926184e2..1c55265be2469 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -3453,6 +3453,56 @@ static void __perf_pmu__probe(struct perf_pmu *pmu, int pmu_cpu)
>  	if (pmu->probed.can_sample)
>  		probe_sample_types(pmu, &base_attr, pid, cpu, flags);
>  
> +	/*
> +	 * 3. Precise sampling support (:p, :pp, :ppp).
> +	 * PMUs that do not validate attr.precise_ip (such as software,
> +	 * breakpoint, or intel_pt) silently accept precise_ip > 0 even when
> +	 * sample_period == 0. A PMU that genuinely implements precise_ip
> +	 * either rejects precise_ip > 0 on non-sampling events or is a
> +	 * sampling-only PMU (such as AMD ibs_op).
> +	 * Note: On AMD, core events like cycles:P are forwarded to IBS and
> +	 * support higher precision than advertised in sysfs caps/max_precise.
> +	 */
> +	if (pmu->probed.can_sample && !pmu->auxtrace) {
> +		bool ignores_precise_ip = false;
> +
> +		if (pmu->probed.can_count) {
> +			struct perf_event_attr c_attr = base_attr;
> +			int fd;
> +
> +			c_attr.sample_period = 0;
> +			c_attr.freq = 0;
> +			c_attr.sample_type = 0;
> +			c_attr.precise_ip = 1;
> +			fd = sys_perf_event_open(&c_attr, pid, cpu, -1, flags);
> +			if (fd >= 0) {
> +				close(fd);
> +				ignores_precise_ip = true;
> +			}
> +		}

[Severity: Medium]
Can guarding the ignores_precise_ip check with pmu->probed.can_count
cause __perf_pmu__probe() to misreport probed.max_precise = 3 and
probed.precise_mask = 0xe on sampling-only PMUs?

For AMD IBS, the kernel only checks event->attr.precise_ip when forwarding
a core PMU event via amd_pmu_hw_config() -> forward_event_to_ibs():

arch/x86/events/amd/ibs.c:forward_event_to_ibs() {
	if (!event->attr.precise_ip || event->attr.precise_ip > 2)
		return -EOPNOTSUPP;
	...
}

When ibs_op or ibs_fetch is opened directly via its own PMU type, the
event_init callback is perf_ibs_init(), which rejects sample_period == 0
(so pmu->probed.can_count is false) and never checks event->attr.precise_ip.
As a result, probing ibs_op and ibs_fetch directly succeeds for levels 1, 2,
and 3 even though IBS only supports levels 1 and 2 (and core forwarding only
targets ibs_op).

Similarly, non-auxtrace sampling-only PMUs on other architectures reject
counting events while ignoring attr.precise_ip on sampling events, such as
PowerPC vpa_dtl and trace_imc:

arch/powerpc/perf/vpa-dtl.c:vpa_dtl_event_init() {
	/* Return if this is a counting event */
	if (!is_sampling_event(event))
		return -EOPNOTSUPP;
	...
}

arch/powerpc/perf/imc-pmu.c:trace_imc_event_init() {
	/* Return if this is a couting event */
	if (event->attr.sample_period == 0)
		return -ENOENT;
	...
}

as well as s390 cpum_sf in __hw_perf_event_init() -> hw_perf_event_reset().
Because pmu->probed.can_count is false for these PMUs, ignores_precise_ip
remains false and all three precise_ip levels will be reported as supported.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103234502.1008382-1-irogers@google.com?part=30