All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "James Clark" <james.clark@linaro.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v3 3/6] perf arm_spe: Store MIDR in arm_spe_pkt
Date: Tue, 14 Apr 2026 13:27:54 +0000	[thread overview]
Message-ID: <20260414132754.90BCDC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260414-james-spe-impdef-decode-v3-3-63baf9c893b1@linaro.org>

Sashiko AI review found 1 potential issue(s):
- [Medium] Unconditional calls to `arm_spe__get_midr()` with an unknown CPU (-1) cause massive un-ratelimited `pr_err` console spam on heterogeneous systems when decoding per-thread traces.
--

commit 1f340d9a2571e040cbd5dd8740efe18dff0e27aa
Author: James Clark <james.clark@linaro.org>

perf arm_spe: Store MIDR in arm_spe_pkt

This patch stores a copy of the MIDR in the arm_spe_pkt structure to
affect the printing of arm_spe_pkts in raw dump mode, and additionally
updates the decoder to contain the MIDR.

> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> index f9188fdb8e786..ed4515fef2de3 100644
> --- a/tools/perf/util/arm-spe.c
> +++ b/tools/perf/util/arm-spe.c

[ ... ]

> @@ -302,8 +305,10 @@ static void arm_spe_set_pid_tid_cpu(struct arm_spe *spe,
>  
>  	if (speq->thread) {
>  		speq->pid = thread__pid(speq->thread);
> -		if (queue->cpu == -1)
> +		if (queue->cpu == -1) {
>  			speq->cpu = thread__cpu(speq->thread);
> +			arm_spe__get_midr(spe, speq->cpu, &speq->decoder->midr);

If the thread's CPU is unknown, can thread__cpu() return -1 here?

If so, could this cause arm_spe__get_midr() to fail and print un-ratelimited
errors (such as "Failed to get MIDR for CPU -1") on heterogeneous systems?
Because arm_spe_set_pid_tid_cpu() is called for trace chunks in the queue
processing loop, would this flood the console with errors?

> +		}
>  	}
>  }
>  
> @@ -1248,6 +1253,7 @@ static int arm_spe__setup_queue(struct arm_spe *spe,
>  
>  	if (queue->cpu != -1)
>  		speq->cpu = queue->cpu;
> +	arm_spe__get_midr(spe, queue->cpu, &speq->decoder->midr);

In per-thread recording mode, queue->cpu can be -1. Does calling
arm_spe__get_midr() unconditionally with -1 result in the same console spam
mentioned above?

>  
>  	if (!speq->on_heap) {
>  		int ret;

[ ... ]

> @@ -1490,8 +1496,11 @@ static int arm_spe_process_auxtrace_event(struct perf_session *session,
>  		/* Dump here now we have copied a piped trace out of the pipe */
>  		if (dump_trace) {
>  			if (auxtrace_buffer__get_data(buffer, fd)) {
> +				u64 midr = 0;
> +
> +				arm_spe__get_midr(spe, buffer->cpu.cpu, &midr);

Similarly, can buffer->cpu.cpu be -1 here, leading to the same console issue
when processing raw buffers?

>  				arm_spe_dump_event(spe, buffer->data,
> -						buffer->size);
> +						   buffer->size, midr);
>  				auxtrace_buffer__put_data(buffer);
>  			}
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260414-james-spe-impdef-decode-v3-0-63baf9c893b1@linaro.org?part=3

  reply	other threads:[~2026-04-14 13:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 11:04 [PATCH v3 0/6] perf arm_spe: Dump IMPDEF events James Clark
2026-04-14 11:04 ` [PATCH v3 1/6] perf arm_spe: Make a function to get the MIDR James Clark
2026-04-14 11:14   ` sashiko-bot
2026-04-14 11:04 ` [PATCH v3 2/6] perf arm_spe: Handle missing CPU IDs James Clark
2026-04-14 11:28   ` sashiko-bot
2026-04-14 11:04 ` [PATCH v3 3/6] perf arm_spe: Store MIDR in arm_spe_pkt James Clark
2026-04-14 13:27   ` sashiko-bot [this message]
2026-04-14 11:04 ` [PATCH v3 4/6] perf arm_spe: Turn event name mappings into an array James Clark
2026-04-14 11:04 ` [PATCH v3 5/6] perf arm_spe: Decode Arm N1 IMPDEF events James Clark
2026-04-14 17:09   ` sashiko-bot
2026-04-14 11:04 ` [PATCH v3 6/6] perf arm_spe: Print remaining IMPDEF event numbers James Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260414132754.90BCDC19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=james.clark@linaro.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.