All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH perf-tools-next 2/3] perf trace: Auto-assign kernel symbol beautifier to function pointer fields
Date: Sat, 15 Aug 2026 23:47:37 +0000	[thread overview]
Message-ID: <20260815234738.393B21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260815233651.527936-3-atomlin@atomlin.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Overly broad name-matching heuristics in `syscall_arg_fmt__init_array()` unconditionally intercept non-function pointer fields, corrupting trace output.
- [Medium] Handling of the `work` field fails to symbolize pointers as intended while corrupting unrelated non-pointer integer fields.
- [Low] Redundant entries added to the `syscall_arg_fmts__by_name` lookup table are completely unreachable dead code.
--

--- Patch [2]: [PATCH perf-tools-next 2/3] perf trace: Auto-assign kernel symbol beautifier to function pointer fields ---
commit e41ca802a20df2b74611c38302bea036b4cc9f1f
Author: Aaron Tomlin <atomlin@atomlin.com>

perf trace: Auto-assign kernel symbol beautifier to function pointer fields

This patch enhances syscall_arg_fmt__init_array() to detect kernel function
pointers and assign SCA_KSYM as their default beautifier. It also registers
common function pointer field names in the syscall_arg_fmts__by_name lookup
table to automatically symbolize them.

> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index 102221b301a54..825b16581581b 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -2091,8 +2091,13 @@ 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 = "callsite",	.scnprintf = SCA_KSYM, },
> +	{ .name = "fn",		.scnprintf = SCA_KSYM, },
> +	{ .name = "function",	.scnprintf = SCA_KSYM, },

[Severity: Low]
Are these lookup table entries reachable? 

In syscall_arg_fmt__init_array(), there is an else-if block added by this
patch that explicitly intercepts these exact field names. It appears these
lookup table entries would never be evaluated for these strings.

>  	{ .name = "msr",	.scnprintf = SCA_X86_MSR,	  .strtoul = STUL_X86_MSR,	   },
>  	{ .name = "vector",	.scnprintf = SCA_X86_IRQ_VECTORS, .strtoul = STUL_X86_IRQ_VECTORS, },
> +	{ .name = "work",	.scnprintf = SCA_KSYM, },

[Severity: Medium]
Does this correctly symbolize work pointers, and could it inadvertently
corrupt unrelated non-pointer integer fields?

For workqueue tracepoints where the work field is a pointer, it appears it
will be intercepted earlier in syscall_arg_fmt__init_array() by the
(field->flags & TEP_FIELD_IS_POINTER) check. That check assigns SCA_PTR 
instead of allowing the field to reach this lookup table.

Conversely, for tracepoints like napi_poll that have a non-pointer integer
field named "work", the pointer check is skipped, allowing it to hit this
lookup table. Wouldn't this assign SCA_KSYM to the integer, causing it to
erroneously print as a hex pointer or NULL instead of a decimal number?

[ ... ]

> @@ -2193,6 +2198,14 @@ syscall_arg_fmt__init_array(struct syscall_arg_fmt *arg, struct tep_format_field
>  		    ((len >= 4 && strcmp(field->name + len - 4, "name") == 0) ||
>  		     strstr(field->name, "path") != NULL)) {
>  			arg->scnprintf = SCA_FILENAME;
> +		} else if (strcmp(field->name, "fn") == 0 ||
> +			   strcmp(field->name, "function") == 0 ||
> +			   strcmp(field->name, "callsite") == 0 ||
> +			   strcmp(field->name, "action") == 0 ||
> +			   (field->type && (strstr(field->type, "(*)") != NULL ||
> +					    strstr(field->type, "_func_t") != NULL ||
> +					    strstr(field->type, "_fn") != NULL))) {
> +			arg->scnprintf = SCA_KSYM;

[Severity: Medium]
Does this unconditional name matching affect non-pointer integer fields
that happen to share these generic names? 

If a tracepoint has an integer field named "action" or "function" (which
can occur in subsystems like btrfs, power, or xfs), wouldn't this assign
SCA_KSYM to it regardless of its actual type? 

This might cause perf trace to treat simple integers as kernel addresses,
failing to resolve a symbol and formatting them incorrectly.

>  		} else if ((field->flags & TEP_FIELD_IS_POINTER) || strstr(field->name, "addr") ||
>  			   field_has_hex_fmt(field, len))
>  			arg->scnprintf = SCA_PTR;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260815233651.527936-1-atomlin@atomlin.com?part=2

  reply	other threads:[~2026-08-15 23:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15 23:36 [PATCH perf-tools-next 0/3] perf trace: Symbolise kernel virtual addresses and function pointers Aaron Tomlin
2026-08-15 23:36 ` [PATCH perf-tools-next 1/3] perf trace: Introduce kernel symbol beautifier for virtual addresses Aaron Tomlin
2026-08-15 23:44   ` sashiko-bot
2026-08-16  1:50     ` Aaron Tomlin
2026-08-15 23:36 ` [PATCH perf-tools-next 2/3] perf trace: Auto-assign kernel symbol beautifier to function pointer fields Aaron Tomlin
2026-08-15 23:47   ` sashiko-bot [this message]
2026-08-15 23:36 ` [PATCH perf-tools-next 3/3] perf trace: Enhance BTF type formatting to symbolise kernel function pointers Aaron Tomlin
2026-08-15 23:50   ` 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=20260815234738.393B21F000E9@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.