Re: [PATCH v9 07/18] perf machine: Use perf_env e_machine rather than arch

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] machine__is() incorrectly falls back to the compile-time host architecture when the machine's environment is NULL, breaking non-x86_64 guest kernel memory map handling.
- [High] get_leaf_frame_caller() delegates to thread__e_machine(), which unconditionally falls back to the host architecture if maps fail, breaking offline cross-architecture callchain analysis.
--

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

perf machine: Use perf_env e_machine rather than arch

This commit modifies perf's machine parsing to use ELF machine constants
instead of architecture strings. This is intended to provide more precise
comparisons by using the thread's e_machine and avoids issues with normalized
architecture strings.

> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index e76f8c86e62a..6d32d3cb5cb7 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1611,10 +1611,15 @@ static bool machine__uses_kcore(struct machine *machine)
>  	return dsos__for_each_dso(&machine->dsos, machine__uses_kcore_cb, NULL) != 0 ? true : false;
>  }
>  
> +static bool machine__is(struct machine *machine, uint16_t e_machine)
> +{
> +	return machine && perf_env__e_machine(machine->env, NULL) == e_machine;
> +}

Could this fallback to the host architecture when dealing with guest machines
that don't have their environment populated?

Guest machines initialized via machines__add do not have their machine->env
populated (machine->env == NULL). Previously, machine__is(..., "x86_64") used
perf_env__raw_arch(NULL), which returned "unknown", safely evaluating to
false.

The new implementation uses perf_env__e_machine(NULL, NULL), which evaluates
to perf_env__e_machine_nocache() and unconditionally returns EM_HOST (the
architecture the perf binary was compiled for).

When analyzing non-x86_64 guests on an x86_64 host, machine__is(guest,
EM_X86_64) evaluates to true.

[ ... ]

> @@ -2770,7 +2775,7 @@ static int find_prev_cpumode(struct ip_callchain *chain, struct thread *thread,
>  static u64 get_leaf_frame_caller(struct perf_sample *sample,
>  		struct thread *thread, int usr_idx)
>  {
> -	if (machine__normalized_is(maps__machine(thread__maps(thread)), "arm64"))
> +	if (thread__e_machine(thread, /*machine=*/NULL, /*e_flags=*/NULL) == EM_AARCH64)
>  		return get_leaf_frame_caller_aarch64(sample, thread, usr_idx);
>  	else
>  		return 0;

Will this break offline cross-architecture callchain analysis for AArch64?

Previously, get_leaf_frame_caller() used machine__normalized_is(), which
correctly checked the session's recorded perf_env (derived from the perf.data
header) to determine the architecture.

The new code relies on thread__e_machine() returning EM_AARCH64. If
thread__e_machine() cannot determine the architecture from the thread's
DSOs (for example, due to stripped binaries, kernel threads, or JIT code),
it falls back to read_proc_e_machine_for_pid().

Since offline perf.data files are not part of a live session, this bypasses
/proc reads and unconditionally defaults to EM_HOST (the compile-time
architecture of the perf binary). As a result, analyzing an AArch64 perf.data
file on an x86_64 host will silently fall back to EM_X86_64, bypassing
get_leaf_frame_caller_aarch64() and preventing leaf frame unwinding.

[ ... ]

> @@ -3181,7 +3172,7 @@ int machine__get_kernel_start(struct machine *machine)
>  		 * start of kernel text, but still above 2^63. So leave
>  		 * kernel_start = 1ULL << 63 for x86_64.
>  		 */
> -		if (!err && !machine__is(machine, "x86_64"))
> +		if (!err && !machine__is(machine, EM_X86_64))
>  			machine->kernel_start = map__start(map);
>  	}
>  	return err;

If machine__is() erroneously returns true for non-x86_64 guests (as noted
above), could this leave machine->kernel_start at 1ULL << 63 and corrupt
kernel address resolution for cross-architecture guest analysis?

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