All of lore.kernel.org
 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 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.