Linux Trace Kernel
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/4] tracing: add __print_sym() to replace __print_symbolic()
Date: Tue, 22 Sep 2026 10:15:57 +0000	[thread overview]
Message-ID: <20260922101557.92FAB1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260921101538.97286-7-johannes@sipsolutions.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] tracing: unaligned access in ftrace_sym_defs section causes kernel panic
--

commit e2d306a70156a518ace125ae399dac289ad0b9ff
Author: Johannes Berg <johannes.berg@intel.com>

tracing: add __print_sym() to replace __print_symbolic()

The way __print_symbolic() works is limited and inefficient in multiple ways.
This commit introduces __print_sym() to replace it, requiring only a single
list of items created by TRACE_DEFINE_SYM_LIST() and doing the fixup when
userspace reads the print_fmt.

> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index b2988aa12f664..e48327fafdfe8 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -276,8 +276,10 @@
>  	. = ALIGN(8);							\
>  	BOUNDED_SECTION(_ftrace_events)					\
>  	BOUNDED_SECTION_BY(_ftrace_eval_map, _ftrace_eval_maps)
> +#define FTRACE_SYM_DEFS()	BOUNDED_SECTION(_ftrace_sym_defs)

[Severity: High]
Does this missing . = ALIGN(8); before BOUNDED_SECTION(_ftrace_sym_defs) in
include/asm-generic/vmlinux.lds.h within FTRACE_SYM_DEFS() cause unaligned
addresses to be captured? Since FTRACE_SYM_DEFS follows TRACEPOINT_STR() which
contains 1-byte aligned strings, the linker might assign an unaligned location
counter to __start_ftrace_sym_defs before adding padding.

>  #else
>  #define FTRACE_EVENTS()
> +#define FTRACE_SYM_DEFS()
>  #endif

[ ... ]

> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 9dbc2441763b1..f14646ba9b22d 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -2109,6 +2109,102 @@ static void *f_next(struct seq_file *m, void *v, loff_t *pos)
>  		return node;
>  }
>  
> +extern struct trace_sym_def *__start_ftrace_sym_defs[];
> +extern struct trace_sym_def *__stop_ftrace_sym_defs[];
> +
> +/* note: @name is not NUL-terminated */
> +static void show_sym_list(struct seq_file *m, struct trace_event_call *call,
> +			  const char *name, unsigned int name_len)
> +{
> +	struct trace_sym_def **sym_defs;
> +	unsigned int n_sym_defs, i;
> +
> +	if ((call->flags & TRACE_EVENT_FL_DYNAMIC) || !call->module) {
> +		sym_defs = __start_ftrace_sym_defs;
> +		n_sym_defs = __stop_ftrace_sym_defs - __start_ftrace_sym_defs;
> +	} else {

[ ... ]

> +
> +	for (i = 0; i < n_sym_defs; i++) {
> +		unsigned int sym_len;
> +
> +		if (!sym_defs[i])
> +			continue;
> +		if (sym_defs[i]->system != call->class->system)

[Severity: High]
If __start_ftrace_sym_defs was given an unaligned address in the linker script,
could this regression in show_sym_list() in kernel/trace/trace_events.c
dereference padding bytes as partial pointers and cause a kernel panic?
This seems reachable by any user with read access to the tracefs format
file for events using __print_sym.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921101538.97286-6-johannes@sipsolutions.net?part=1

  reply	other threads:[~2026-09-22 10:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 10:06 [PATCH v6 0/4] tracing: improve symbolic printing Johannes Berg
2026-09-21 10:06 ` [PATCH v6 1/4] tracing: add __print_sym() to replace __print_symbolic() Johannes Berg
2026-09-22 10:15   ` sashiko-bot [this message]
2026-09-21 10:06 ` [PATCH v6 2/4] tracing/timer: use __print_sym() Johannes Berg
2026-09-21 10:06 ` [PATCH v6 3/4] net: dropreason: use new __print_sym() in tracing Johannes Berg
2026-09-21 22:03   ` Matthieu Baerts
2026-09-21 22:23     ` Ilya Maximets
2026-09-21 22:36       ` Johannes Berg
2026-09-21 23:20         ` Johannes Berg
2026-09-22  9:01           ` Ilya Maximets
2026-09-22  9:03             ` Johannes Berg
2026-09-22 14:36             ` Adrián Moreno
2026-09-22 15:34             ` Aaron Conole
2026-09-28 15:21             ` Matthieu Baerts
2026-09-22  7:18       ` Antoine Tenart
2026-09-22  8:48         ` Ilya Maximets
2026-09-22 14:35       ` Adrián Moreno
2026-09-22 14:59         ` Johannes Berg
2026-09-21 10:06 ` [PATCH v6 4/4] net: drop_monitor: use drop_reason_lookup() Johannes Berg
2026-09-22 10:15   ` sashiko-bot
2026-09-21 21:59 ` [PATCH v6 0/4] tracing: improve symbolic printing Jakub Kicinski

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=20260922101557.92FAB1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-trace-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox