All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: sashiko@lists.linux.dev
Cc: James Clark <james.clark@linaro.org>, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v4 5/6] perf arm_spe: Decode Arm N1 IMPDEF events
Date: Tue, 5 May 2026 22:01:56 -0300	[thread overview]
Message-ID: <afqTBBXcPmobSCu1@x1> (raw)
In-Reply-To: <20260414155203.0B24CC19425@smtp.kernel.org>

On Tue, Apr 14, 2026 at 03:52:02PM +0000, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 1 potential issue(s):
> - [Low] The relative include path `#include "../../arm64/include/asm/cputype.h"` is invalid and relies on accidental directory traversal through a compiler `-I` flag.
> --
> 
> commit 7fc153524fe60dc6d6f08fd73b7ea3f46e904e39
> Author: James Clark <james.clark@linaro.org>
> 
> perf arm_spe: Decode Arm N1 IMPDEF events
> 
> This commit adds a framework to decode the N1 IMPDEF event for Arm SPE, 
> which isn't covered by the common list. It also increases the packet 
> description buffer size to accommodate more strings without falling back 
> to a hex dump.
> 
> Link: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
> 
> > diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
> > index ab500e0efe244..97a298d1e2791 100644
> > --- a/tools/perf/util/arm-spe-decoder/Build
> > +++ b/tools/perf/util/arm-spe-decoder/Build
> > @@ -1 +1,3 @@
> >  perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
> > +
> > +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
> 
> [ ... ]
> 
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 67ca356100e53..b74f887a48f2a 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -15,6 +15,8 @@
> >  
> >  #include "arm-spe-pkt-decoder.h"
> >  
> > +#include "../../arm64/include/asm/cputype.h"
> 
> Is this relative include path correct?
> 
> It looks like this file is located in tools/perf/util/arm-spe-decoder/, so
> the relative path resolves to tools/perf/arm64/include/asm/cputype.h,
> which doesn't exist.
> 
> It seems this only compiles because the newly added -I flag in the Build
> file causes the preprocessor to resolve the include relative to
> tools/arch/arm64/include/. The path then inadvertently evaluates back to the
> correct file by traversing backwards out of the include directory and diving
> back in.
> 
> Could this be made less brittle by relying directly on the include flag,
> using #include <asm/cputype.h> instead?

This is just a possible improvement and not strictly a problem as the -I
is structured today, so lets not postpone processing this patchset
because of this, this can be considered some other time.

- Arnaldo

  reply	other threads:[~2026-05-06  1:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 12:47 [PATCH v4 0/6] perf arm_spe: Dump IMPDEF events James Clark
2026-04-14 12:47 ` [PATCH v4 1/6] perf arm_spe: Make a function to get the MIDR James Clark
2026-04-14 12:48 ` [PATCH v4 2/6] perf arm_spe: Handle missing CPU IDs James Clark
2026-04-14 12:48 ` [PATCH v4 3/6] perf arm_spe: Store MIDR in arm_spe_pkt James Clark
2026-04-14 12:48 ` [PATCH v4 4/6] perf arm_spe: Turn event name mappings into an array James Clark
2026-04-14 12:48 ` [PATCH v4 5/6] perf arm_spe: Decode Arm N1 IMPDEF events James Clark
2026-04-14 15:52   ` sashiko-bot
2026-05-06  1:01     ` Arnaldo Carvalho de Melo [this message]
2026-05-06  8:39       ` James Clark
2026-04-14 12:48 ` [PATCH v4 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=afqTBBXcPmobSCu1@x1 \
    --to=acme@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.