Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] User-controllable command-line arguments inappropriately trigger a WARN_ON(). --
--- Patch [16]: [PATCH v5 16/18] tracing/remotes: Add trace_remote cmdline options --- commit 473129b2ec6ced6d4d23093ce86b83497f7202d2 Author: Vincent Donnefort <[email protected]> tracing/remotes: Add trace_remote cmdline options This commit adds a trace_remote= boot command-line option to configure a trace remote upon registration. It enables configuring various options like buffer size, polling interval, and activating specific tracing events. > diff --git a/kernel/trace/trace_remote.c b/kernel/trace/trace_remote.c > index b1c75666ab638..8764d0ed39097 100644 > --- a/kernel/trace/trace_remote.c > +++ b/kernel/trace/trace_remote.c [ ... ] > @@ -1169,6 +1171,124 @@ static int poll_ms_show(struct seq_file *s, void > *unused) [ ... ] > +static void trace_remote_apply_cmdline_opts(struct trace_remote *remote, > char *cmdline) > +{ [ ... ] > + } else if (!strncmp(opt, "buf_size=", 9)) { > + /* buf_size can only be applied if the buffer is > unloaded */ > + if (!WARN_ON(trace_remote_loaded(remote))) > + remote->trace_buffer_size = memparse(opt + 9, > NULL); [Severity: Medium] Should this be a pr_warn() instead of a WARN_ON()? If the bootloader passes multiple trace_remote= parameters, and an earlier parameter enables events (which loads the buffer) before a later parameter tries to set buf_size= for the same remote, this check will fail and emit a warning. Because WARN_ON() is used here, a simple typo or misordered boot command line will trigger a splat and cause a kernel panic during boot on any system configured with panic_on_warn. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=16
