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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.