From: Steven Rostedt <rostedt@goodmis.org>
To: Wesley Atwell <atwellwea@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v5] tracing: Preserve repeated boot-time tracing parameters
Date: Sun, 29 Mar 2026 11:49:41 -0400 [thread overview]
Message-ID: <20260329114941.25d3541d@robin> (raw)
In-Reply-To: <20260328201842.1782806-1-atwellwea@gmail.com>
On Sat, 28 Mar 2026 14:18:42 -0600
Wesley Atwell <atwellwea@gmail.com> wrote:
> Some tracing boot parameters already accept delimited value lists, but
> their __setup() handlers keep only the last instance seen at boot.
> Make repeated instances append to the same boot-time buffer in the
> format each parser already consumes.
>
> Use a shared trace_append_boot_param() helper for the ftrace filters,
> trace_options, and kprobe_event boot parameters. trace_trigger=
> tokenizes its backing storage in place, so keep a running offset and
> only parse the newly appended chunk into bootup_triggers[].
>
> This also lets Bootconfig array values work naturally when they expand
> to repeated param=value entries.
>
> Validated by booting with repeated ftrace_filter=, ftrace_notrace=,
> ftrace_graph_filter=, ftrace_graph_notrace=, trace_options=,
> kprobe_event=, and trace_trigger= parameters and confirming that the
> resulting tracefs state preserved every requested entry. Before this
> change, only the last instance from each repeated parameter survived
> boot.
>
> Signed-off-by: Wesley Atwell <atwellwea@gmail.com>
> ---
> v5:
FYI, it's nice to have a daisy chain connection of previous versions. I
suggest instead of just saying "v5:" use:
Changes since v4: https://lore.kernel.org/all/20260324221326.1395799-2-atwellwea@gmail.com/
> - use int sizes in the shared append helper and trace_trigger bookkeeping
> - keep a single bounded append path that only inserts the separator after
> the first entry
> - only advance the trace_trigger buffer offset after a successful append
>
> kernel/trace/ftrace.c | 12 ++++++++----
> kernel/trace/trace.c | 29 ++++++++++++++++++++++++++++-
> kernel/trace/trace.h | 2 ++
> kernel/trace/trace_events.c | 23 ++++++++++++++++++++---
> kernel/trace/trace_kprobe.c | 3 ++-
> 5 files changed, 60 insertions(+), 9 deletions(-)
>
> +/*
> + * Repeated boot parameters, including Bootconfig array expansions, need
> + * to stay in the delimiter form that the existing parser consumes.
> + */
> +void __init trace_append_boot_param(char *buf, const char *str, char sep,
> + int size)
> +{
This is much better.
> + int len, needed, str_len;
> +
> + if (!*str)
> + return;
> +
> + len = strlen(buf);
> + str_len = strlen(str);
> + needed = len + str_len + 1;
Perhaps add a comment:
/* For continuation, account for separator */
> + if (len)
> + needed++;
> + if (needed > size)
> + return;
> +
> + if (len)
> + buf[len++] = sep;
> +
> + strscpy(buf + len, str, size - len);
> +}
> +
> static int __init set_cmdline_ftrace(char *str)
> {
> strscpy(bootup_tracer_buf, str, MAX_TRACER_SIZE);
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -3679,20 +3679,37 @@ static struct boot_triggers {
> } bootup_triggers[MAX_BOOT_TRIGGERS];
>
> static char bootup_trigger_buf[COMMAND_LINE_SIZE];
> +static int bootup_trigger_buf_len;
> static int nr_boot_triggers;
>
> static __init int setup_trace_triggers(char *str)
> {
> + char *slot;
> char *trigger;
> char *buf;
> int i;
>
> - strscpy(bootup_trigger_buf, str, COMMAND_LINE_SIZE);
> + if (bootup_trigger_buf_len >= COMMAND_LINE_SIZE)
> + return 1;
> +
> + slot = bootup_trigger_buf + bootup_trigger_buf_len;
The bootup_trigger_buf is a temporary buffer for this function only. It
works fine as is. There's no reason to modify this function.
-- Steve
> +
> + /*
> + * trace_trigger= parsing tokenizes the backing storage in place.
> + * Copy each repeated parameter into fresh space and only parse that
> + * newly copied chunk here.
> + */
> + trace_append_boot_param(slot, str, '\0',
> + COMMAND_LINE_SIZE - bootup_trigger_buf_len);
> + if (!*slot)
> + return 1;
> +
> + bootup_trigger_buf_len += strlen(slot) + 1;
> trace_set_ring_buffer_expanded(NULL);
> disable_tracing_selftest("running event triggers");
>
> - buf = bootup_trigger_buf;
> - for (i = 0; i < MAX_BOOT_TRIGGERS; i++) {
> + buf = slot;
> + for (i = nr_boot_triggers; i < MAX_BOOT_TRIGGERS; i++) {
> trigger = strsep(&buf, ",");
> if (!trigger)
> break;
next prev parent reply other threads:[~2026-03-29 15:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 22:13 [PATCH v4 0/2] tracing: Preserve repeated boot-time parameters and drain deferred trigger frees Wesley Atwell
2026-03-24 22:13 ` [PATCH v4 1/2] tracing: Preserve repeated boot-time tracing parameters Wesley Atwell
2026-03-28 17:53 ` Steven Rostedt
2026-03-28 20:18 ` [PATCH v5] " Wesley Atwell
2026-03-29 15:49 ` Steven Rostedt [this message]
2026-03-29 18:42 ` [PATCH v6] " Wesley Atwell
2026-03-30 14:43 ` Steven Rostedt
2026-03-30 16:37 ` Steven Rostedt
2026-03-30 16:42 ` Steven Rostedt
2026-03-24 22:13 ` [PATCH v4 2/2] tracing: Drain deferred trigger frees if kthread creation fails Wesley Atwell
2026-03-27 19:06 ` Steven Rostedt
2026-03-27 22:41 ` Wesley Atwell
2026-03-28 2:30 ` Steven Rostedt
2026-03-28 4:56 ` Wesley Atwell
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=20260329114941.25d3541d@robin \
--to=rostedt@goodmis.org \
--cc=atwellwea@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
/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.