Re: [PATCH v9 5/9] perf cs-etm: Use thread-stack for last branch entries

[Leo Yan <leo.yan@arm.com>]

On Tue, Jun 16, 2026 at 03:13:13PM +0000, sashiko-bot@kernel.org wrote:

[...]

> > @@ -2025,7 +1965,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq,
> >  
> >  	/* Reset last branches after flush the trace */
> >  	if (etm->synth_opts.last_branch)
> > -		cs_etm__reset_last_branch_rb(tidq);
> > +		thread_stack__flush(tidq->frontend_thread);
> 
> [Severity: High]
> Can this cause cross-CPU state corruption when flushing shared thread stacks?
> 
> When cs_etm__flush() is called due to a local trace discontinuity or the end of
> a block on a specific trace queue (CPU), it calls thread_stack__flush() on
> the frontend_thread.
> 
> If the traced thread is shared across multiple CPUs (such as the global idle
> thread pid == 0), thread_stack__flush() will iterate over ts->arr_sz and
> reset the branch stacks for all CPUs associated with that thread:
> 
> tools/perf/util/thread-stack.c:thread_stack__flush() {
> 	...
> 	for (pos = 0; pos < ts->arr_sz; pos++) {
> 		int ret = __thread_stack__flush(thread, ts + pos);
> 	...
> }
> 
> This replaces the previously safe localized reset for the trace queue with a
> global flush. Could a localized discontinuity on CPU A silently wipe out the
> active branch stack and callchain history of the shared thread executing
> concurrently on CPU B?

So far, this only affects idle threads across CPUs. In most cases, idle
threads are not the profiling target, and it requires to refactor the
common code that manages idle threads on a per-CPU basis.

I would defer this until there is a clear requirement.

That said, I hope we rather spend time to improve cs-etm discontinuity
issue (from both driver and tooling).