Re: [PATCH v6 4/8] perf cs-etm: Flush thread stacks after decoder reset

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Flushing all thread stacks globally across the machine upon a per-queue decoder reset corrupts callchains for threads executing on other CPUs.
- [Medium] The thread stack flush callback silently ignores errors returned by `thread_stack__flush()`.
--

commit 5bb375ff87340381fc1d45a283d0256f7738d4d0
Author: Leo Yan <leo.yan@arm.com>

perf cs-etm: Flush thread stacks after decoder reset

Perf resets the CoreSight decoder when moving to a new AUX trace buffer,
causing a global trace discontinuity. To prevent stale call and return
history from attaching to later threads, this patch flushes all host and
guest thread stacks after a decoder reset.

> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 398ab3b7a429d..ea2424175558d 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
[ ... ]
> +static int cs_etm__flush_stack_cb(struct thread *thread,
> +				  void *data __maybe_unused)
> +{
> +	thread_stack__flush(thread);
> +	return 0;
> +}

[Severity: Medium]
Does this callback safely ignore errors from thread_stack__flush()?

thread_stack__flush() can return error codes such as -ENOMEM when memory
allocation fails during call and return synthesis. Returning 0 unconditionally
prevents machine__for_each_thread() from aborting early, but it also
silently drops the error.

Could this mask underlying synthesis failures?

> +
> +static void cs_etm__flush_machine_stack(struct cs_etm_queue *etmq, pid_t pid)
> +{
> +	struct machine *machine;
> +
> +	machine = machines__find(&etmq->etm->session->machines, pid);
> +	if (machine)
> +		machine__for_each_thread(machine, cs_etm__flush_stack_cb, NULL);
> +}

[Severity: Medium]
Does flushing all threads globally cause issues for other CPUs?

In CoreSight tracing, traces are decoded using per-CPU queues. When one
cs_etm_queue encounters a trace discontinuity, calling
machine__for_each_thread() will flush the call stacks for all threads in
the machine.

Could this destroy the call and return state of threads that are actively
executing and being decoded on other queues, resulting in corrupted
synthesized callchains for those unrelated threads?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-b4-arm_cs_callchain_support_v1-v6-0-f9f49f53c9dd@arm.com?part=4