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 v7 1/4] tracing: add __print_sym() to replace __print_symbolic()
Date: Wed, 23 Sep 2026 11:10:17 +0000	[thread overview]
Message-ID: <20260923111017.F17CD1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260922110955.363677-7-johannes@sipsolutions.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tracing: show_print_fmt() string parsing breaks if value contains ternary operator
--

commit deeb2ac9d2766875d27bd9a2d5d898875d56cc2a
Author: Johannes Berg <johannes.berg@intel.com>
tracing: add __print_sym() to replace __print_symbolic()

This commit introduces __print_sym() to replace the old __print_symbolic(),
making it more memory efficient and allowing dynamic updates. It relies on a
single dynamic list of items processed at the time userspace reads the
print_fmt, avoiding init-time fixups.

> diff --git a/include/trace/stages/stage7_class_define.h b/include/trace/stages/stage7_class_define.h
> --- a/include/trace/stages/stage7_class_define.h
> +++ b/include/trace/stages/stage7_class_define.h
> @@ -45,6 +45,9 @@
>  #define __event_in_softirq()	(REC->common_flags & 0x10)
>  #define __event_in_irq()	(REC->common_flags & 0x18)
>  
> +#undef __print_sym
> +#define __print_sym(value, symbol_id)	__print_sym(value:symbol_id)

[Severity: Medium]
Does this delimiter choice in the __print_sym() macro in
include/trace/stages/stage7_class_define.h cause issues for arbitrary C
expressions?

This macro transforms the arguments into a string format using a delimiter (:)
that is unsafe for arbitrary C expressions if parsed left-to-right. If a
kernel developer uses an expression containing a colon (such as a ternary
operator like a ? b : c) as the value argument, it seems the string
representation will contain multiple colons.

> +
>  /*
>   * The below is not executed in the kernel. It is only what is
>   * displayed in the print format for userspace to parse.

[ ... ]

> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> --- 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)
[ ... ]
> +static void show_print_fmt(struct seq_file *m, struct trace_event_call *call)
> +{
[ ... ]
> +		if (in_print_sym && *ptr == ':') {
> +			const char *name;
> +
> +			ptr++;
> +			name = ptr;
> +			/* skip the name */
> +			while (*ptr && *ptr != ')')
> +				ptr++;

[Severity: Medium]
Will this parser in show_print_fmt() in kernel/trace/trace_events.c break
if the value expression contains a ternary operator?

It appears this logic naively splits at the first colon, destroying valid C
expressions like ternary operators that natively contain a colon. If a
tracepoint passes a ternary operator to __print_sym(), the parser incorrectly
assumes the first ':' encountered uniquely separates the value expression from
the symbol ID.

This would cause tracing tools to fail parsing the exported print_fmt, breaking
event decoding for userspace.

Could a backward search for ':' from the closing parenthesis safely isolate
the symbol ID?

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

  reply	other threads:[~2026-09-23 11:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 11:08 [PATCH v7 0/4] tracing: improve symbolic printing Johannes Berg
2026-09-22 11:08 ` [PATCH v7 1/4] tracing: add __print_sym() to replace __print_symbolic() Johannes Berg
2026-09-23 11:10   ` sashiko-bot [this message]
2026-09-28 14:19     ` Johannes Berg
2026-09-22 11:08 ` [PATCH v7 2/4] tracing/timer: use __print_sym() Johannes Berg
2026-09-22 11:08 ` [PATCH v7 3/4] net: dropreason: use new __print_sym() in tracing Johannes Berg
2026-09-24 15:31   ` Ilya Maximets
2026-09-28 13:34   ` Aaron Conole
2026-09-22 11:08 ` [PATCH v7 4/4] net: drop_monitor: use drop_reason_lookup() Johannes Berg

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=20260923111017.F17CD1F000FF@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.