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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Guest machine thread stacks (including host kernel threads running at EL1 when context IDs are not traced) are not flushed during a global trace discontinuity when the PID format is CS_ETM_PIDFMT_NONE, leaving the original stale callchain bug unresolved for these threads.
--

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

perf cs-etm: Flush thread stacks after decoder reset

This commit addresses global trace discontinuities when perf resets the
CoreSight decoder. It flushes host thread stacks (and guest thread stacks
when virtualization is supported) to prevent stale call/return history
from producing incorrect synthesized callchains.

> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 8798bf0471faf..7069b4990e610 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c

[ ... ]

> @@ -1997,6 +1997,37 @@ static int cs_etm__end_block(struct cs_etm_queue *etmq,

[ ... ]

> +static void cs_etm__flush_all_stack(struct cs_etm_queue *etmq)
> +{
> +	enum cs_etm_pid_fmt pid_fmt = cs_etm__get_pid_fmt(etmq);
> +
> +	if (!etmq->etm->synth_opts.last_branch)
> +		return;
> +
> +	cs_etm__flush_machine_stack(etmq, HOST_KERNEL_ID);
> +
> +	/* Clear the guest stack if virtualization is supported */
> +	if (pid_fmt == CS_ETM_PIDFMT_CTXTID2)
> +		cs_etm__flush_machine_stack(etmq, DEFAULT_GUEST_KERNEL_ID);

[Severity: Medium]
Will this leave guest machine thread stacks unflushed if the PID format is
CS_ETM_PIDFMT_NONE?

When no context IDs are traced, the fallback logic in cs_etm__get_machine()
assigns EL1 traces to the guest machine:

tools/perf/util/cs-etm.c:cs_etm__get_machine() {
        ...
        switch (el) {
        case ocsd_EL1:
                return machines__find_guest(&etmq->etm->session->machines,
                                            DEFAULT_GUEST_KERNEL_ID);
        ...
}

Since the flush here is strictly gated on CS_ETM_PIDFMT_CTXTID2, does this
skip flushing those threads and leave their original stale call/return
history unresolved?

> +}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-b4-arm_cs_callchain_support_v1-v8-0-737948584fea@arm.com?part=5