Re: [PATCH v10 10/18] perf arch common: Use perf_env e_machine rather than arch

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] `perf_env__single_address_space()` incorrectly drops the `s390` exclusion, returning `true` for `EM_S390` and breaking s390 address resolution.
--

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

perf arch common: Use perf_env e_machine rather than arch

This commit refactors architecture matching in the perf tools to use the ELF
machine constant (e_machine) instead of string matching on the architecture
name.

> diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
> index ad0cab830a4da..805a15ed99bcf 100644
> --- a/tools/perf/arch/common.c
> +++ b/tools/perf/arch/common.c

[ ... ]

> @@ -237,7 +283,7 @@ int perf_env__lookup_objdump(struct perf_env *env, char **path)
>   */
>  bool perf_env__single_address_space(struct perf_env *env)
>  {
> -	const char *arch = perf_env__arch(env);
> +	uint16_t e_machine = perf_env__e_machine(env, /*e_flags=*/NULL);
>  
> -	return strcmp(arch, "s390") && strcmp(arch, "sparc");
> +	return e_machine != EM_SPARC && e_machine != EM_SPARCV9;

[Severity: High]
Does this unintentionally drop the s390 exclusion?

The original code returned false for both "s390" and "sparc", but the updated
logic omits a check for EM_S390, causing it to return true for s390 targets.

Because s390 uses overlapping address spaces for user and kernel space,
treating it as a single address space causes machine__addr_cpumode() to
misclassify user-space addresses as kernel-space (PERF_RECORD_MISC_KERNEL)
if they happen to overlap with kernel memory maps. 

Could this break symbol resolution, callchains, and event attribution for
s390 workloads?

>  }

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