Re: [PATCH v3 2/6] perf arm_spe: Handle missing CPU IDs

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] Unconditional `pr_err()` on the per-sample hot path causes severe log spam and performance degradation.
--

commit be72d9e89c04e5b03be3ccecb3b4bb5f759902c7
Author: James Clark <james.clark@linaro.org>

perf arm_spe: Handle missing CPU IDs

This commit avoids undefined behavior by checking for a null pointer before
calling strtol() during CPU ID lookup. It also adds an error message when
SPE decoding continues with reduced functionality due to a missing MIDR.

> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> --- a/tools/perf/util/arm-spe.c
> +++ b/tools/perf/util/arm-spe.c
> @@ -982,16 +982,23 @@ static int arm_spe__get_midr(struct arm_spe *spe, int cpu, u64 *midr)

[ ... ]

>  	metadata = arm_spe__get_metadata_by_cpu(spe, cpu);
>  	if (!metadata)
> -		return -EINVAL;
> +		goto err;
>  
>  	*midr = metadata[ARM_SPE_CPU_MIDR];
>  	return 0;
> +
> +err:
> +	pr_err("Failed to get MIDR for CPU %d\n", cpu);
> +	return -EINVAL;
>  }

Will this unconditional pr_err() cause severe log spam and performance issues
on the per-sample hot path?

Since arm_spe__get_midr() is invoked continuously via arm_spe__synth_ds(),
there are scenarios where this error path is hit frequently. For example,
when processing a per-thread trace (where cpu is -1) on a heterogeneous
system, arm_spe__get_metadata_by_cpu() returns NULL until a context packet
provides the CPU ID.

In these cases, printing an error for every single sample could flood the
output with millions of messages. Could this be mitigated by using
pr_err_once() or rate-limiting the message instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260414-james-spe-impdef-decode-v3-0-63baf9c893b1@linaro.org?part=2