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 1/6] perf arm_spe: Make a function to get the MIDR
Date: Tue, 14 Apr 2026 11:14:32 +0000	[thread overview]
Message-ID: <20260414111433.19889C19425@smtp.kernel.org> (raw)
In-Reply-To: <20260414-james-spe-impdef-decode-v3-1-63baf9c893b1@linaro.org>

Sashiko AI review found 1 potential issue(s):
- [High] Missing NULL pointer check on the result of `perf_env__cpuid()` leads to a potential segmentation fault in `strtol()`.
--

commit 6dbdbd9b51f99a0d48fd13fa50acc79faa59bbb8
Author: James Clark <james.clark@linaro.org>

perf arm_spe: Make a function to get the MIDR

This commit extracts a function to get the MIDR, which will be needed to
dump IMPDEF events in later commits. No functional changes are intended.

> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> --- a/tools/perf/util/arm-spe.c
> +++ b/tools/perf/util/arm-spe.c
[ ... ]
> @@ -987,15 +982,28 @@ static void arm_spe__synth_ds(struct arm_spe_queue *speq,
>  
>  		pr_warning_once("Old SPE metadata, re-record to improve decode accuracy\n");
>  		cpuid = perf_env__cpuid(perf_session__env(spe->session));
> -		midr = strtol(cpuid, NULL, 16);
> -	} else {
> -		metadata = arm_spe__get_metadata_by_cpu(spe, speq->cpu);
> -		if (!metadata)
> -			return;
> -
> -		midr = metadata[ARM_SPE_CPU_MIDR];
> +		*midr = strtol(cpuid, NULL, 16);

Could this cause a segmentation fault if perf_env__cpuid() returns NULL?

If reading the CPU ID fails (for instance, when processing an SPE trace with
old metadata on a machine lacking the expected sysfs CPU ID files), passing
NULL to strtol() will crash the tool.

I note this behavior was present before this patch, and I see it is addressed
later in the patch series in commit be72d9e89c04e ("perf arm_spe: Handle
missing CPU IDs").

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

  reply	other threads:[~2026-04-14 11:14 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 [this message]
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
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=20260414111433.19889C19425@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.