linux-kernel - Re: [PATCH v2 1/2] perf cs-etm: Fix decoding for sparse CPU maps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260119153846.GD2732125@e132581.arm.com>
Date: Mon, 19 Jan 2026 15:43:18 +0000
From: Leo Yan <leo.yan@....com>
To: James Clark <james.clark@...aro.org>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
	Mike Leach <mike.leach@...aro.org>,
	John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>,
	Leo Yan <leo.yan@...ux.dev>, Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Thomas Falcon <thomas.falcon@...el.com>, coresight@...ts.linaro.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] perf cs-etm: Fix decoding for sparse CPU maps

On Mon, Jan 19, 2026 at 03:16:01PM +0000, James Clark wrote:

[...]

> > > > >    		/*
> > > > >    		 * If this AUX event was inside this buffer somewhere, create a new auxtrace event
> > > > > @@ -3095,6 +3095,7 @@ static int cs_etm__queue_aux_fragment(struct perf_session *session, off_t file_o
> > > > >    		auxtrace_fragment.auxtrace = *auxtrace_event;
> > > > >    		auxtrace_fragment.auxtrace.size = aux_size;
> > > > >    		auxtrace_fragment.auxtrace.offset = aux_offset;
> > > > > +		auxtrace_fragment.auxtrace.idx = etmq->queue_nr;
> > 
> > I am still confused about this.  Because above auxtrace will be queued
> > on cs_etm queues, should we convert from the generic buffer index to the
> > cs_etm specific one?  E.g.,
> > 
> >    auxtrace_fragment.auxtrace.idx = auxtrace_event->cpu;
> > 
> 
> This is basically what the change is already doing. etmq->queue_nr == CPU
> because cs_etm__setup_queue() is called for every CPU up to max_cpu, not
> only for ones that were recorded so it has a 1:1 mapping. Using
> etmq->queue_nr also works in per-thread mode where queue 0 is used, which
> your suggestion doesn't handle. Otherwise they would be equivalent.

Indeed, per-thread mode needs to be handled separately.

On the Juno board (6 CPUs), I see "etmq->queue_nr=6".  It seems a bit
odd that this value is used as the index.  Even in per-thread mode, the
index is still set to 6.  For correctness, should we instead set the
index to the CPU ID, and use 0 for per-thread mode?

> To be honest the whole decoder has become hacks on top of hacks. I think we
> might want to do a full from scratch re-write when we come to do the proper
> timestamp to MMAP event correlation or the change to not keep resetting the
> decoder for TRBE wrap mode.
> 
> > BTW, if my understanding above is valid, it is good to go through the
> > cs_etm.c file for the "idx <-> CPU ID" conversion.
> 
> Do you mean there are other mistakes?

Yes.

> I did check the rest and did some testing and didn't see any issues.

Thanks a lot for the checking.

Leo