From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH perf-tools-next v3 2/4] perf trace: Auto-assign kernel symbol beautifier to function pointer fields
Date: Thu, 20 Aug 2026 21:26:12 +0000 [thread overview]
Message-ID: <20260820212613.504001F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820211100.649142-3-atomlin@atomlin.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Mapping highly generic field names like 'action', 'cb', and 'caller' globally to `SCA_KSYM` short-circuits type-based logic, leaking perf userspace memory addresses instead of strings and breaking integers/enums.
- [Medium] Removal of `trace__field_is_ip()` and omission of `caller_ip` from the new lookup table causes kernel instruction pointers to be formatted as unreadable decimal integers.
--
--- Patch [2]: [PATCH perf-tools-next v3 2/4] perf trace: Auto-assign kernel symbol beautifier to function pointer fields ---
commit d3017d506b83550526e2692582e2544d0b006d0f
Author: Aaron Tomlin <atomlin@atomlin.com>
perf trace: Auto-assign kernel symbol beautifier to function pointer fields
This patch enhances perf trace to automatically format kernel function
pointer fields using the SCA_KSYM beautifier. It detects these fields
by type signature or by matching common function pointer and callback
field names in a lookup table.
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index 0030489465032..bb8f4fd9ba244 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -2096,6 +2096,17 @@ static int syscall__alloc_arg_fmts(struct syscall *sc, int nr_args)
> }
>
> static const struct syscall_arg_fmt syscall_arg_fmts__by_name[] = {
> + { .name = "action", .scnprintf = SCA_KSYM, },
> + { .name = "call_site", .scnprintf = SCA_KSYM, },
> + { .name = "callback", .scnprintf = SCA_KSYM, },
> + { .name = "caller", .scnprintf = SCA_KSYM, },
> + { .name = "callsite", .scnprintf = SCA_KSYM, },
> + { .name = "cb", .scnprintf = SCA_KSYM, },
[ ... ]
> @@ -2230,6 +2220,24 @@ syscall_arg_fmt__init_array(struct syscall_arg_fmt *arg, struct tep_format_field
> if (fmt) {
> arg->scnprintf = fmt->scnprintf;
> arg->strtoul = fmt->strtoul;
> + } else if ((field->flags & TEP_FIELD_IS_POINTER) || strstr(field->name, "addr") ||
> + field_has_hex_fmt(field, len)) {
> + arg->scnprintf = SCA_PTR;
> + } else if (strcmp(field->type, "pid_t") == 0) {
> + arg->scnprintf = SCA_PID;
> + } else if (strcmp(field->type, "umode_t") == 0) {
> + arg->scnprintf = SCA_MODE_T;
> + } else if ((field->flags & TEP_FIELD_IS_ARRAY) && strstr(field->type, "char")) {
> + arg->scnprintf = SCA_CHAR_ARRAY;
> + arg->nr_entries = field->arraylen;
[Severity: High]
Does checking syscall_arg_fmt__find_by_name() earlier in this branch,
before the type-based checks like string arrays or BTF enums, short-circuit
those checks for generic field names?
If a field is named "caller", "action", or "cb" but is actually a dynamic
string or integer, it seems this early name match will blindly assign
SCA_KSYM.
Would this cause strings to be printed as raw kernel addresses by passing a
userspace perf pointer to SCA_KSYM, permanently obfuscating the trace data?
[ ... ]
> @@ -3297,12 +3305,6 @@ static unsigned char bitmap_byte(const unsigned long *mask, int byte_idx)
> return b_val;
> }
>
> -static bool trace__field_is_ip(const char *name)
> -{
> - return !strcmp(name, "__probe_ip") ||
> - !strcmp(name, "caller_ip") ||
> - !strcmp(name, "call_site");
> -}
[Severity: Medium]
Since trace__field_is_ip() is removed here, should "caller_ip" have been
added to the new syscall_arg_fmts__by_name lookup table?
Because "caller_ip" is typed as unsigned long (not a pointer), lacks "addr"
in its name, and its TP_printk format strings do not match the strict
=0x/=%p checks in field_has_hex_fmt(), it evades all heuristics.
Will this cause kernel instruction pointers like "caller_ip" (used heavily
in XFS and OCFS2 tracepoints) to be formatted as unreadable base-10 decimal
integers?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260820211100.649142-1-atomlin@atomlin.com?part=2
next prev parent reply other threads:[~2026-08-20 21:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 21:10 [PATCH perf-tools-next v3 0/4] perf trace: Symbolise kernel virtual addresses and function pointers Aaron Tomlin
2026-08-20 21:10 ` [PATCH perf-tools-next v3 1/4] perf trace: Introduce kernel symbol beautifier for virtual addresses Aaron Tomlin
2026-08-20 21:19 ` sashiko-bot
2026-08-20 21:10 ` [PATCH perf-tools-next v3 2/4] perf trace: Auto-assign kernel symbol beautifier to function pointer fields Aaron Tomlin
2026-08-20 21:26 ` sashiko-bot [this message]
2026-08-21 0:29 ` Aaron Tomlin
2026-08-20 21:10 ` [PATCH perf-tools-next v3 3/4] perf trace: Enhance BTF type formatting to symbolise kernel function pointers Aaron Tomlin
2026-08-20 21:25 ` sashiko-bot
2026-08-20 21:11 ` [PATCH perf-tools-next v3 4/4] perf tests: Add shell test for kernel symbol beautifier Aaron Tomlin
2026-08-20 21:27 ` sashiko-bot
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=20260820212613.504001F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=atomlin@atomlin.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@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.