Re: [PATCH v6 03/18] tracing/remotes: Use kstrtobool for boolean tracefs files
From: Vincent Donnefort <hidden>
Date: 2026-09-24 12:27:46
Also in:
sashiko-reviews
On Mon, Aug 17, 2026 at 02:11:20PM +0000, sashiko-bot@kernel.org wrote:
quoted hunk ↗ jump to hunk
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Kernel infinite loop when reading an oversized trace event from the `trace_pipe` file. ----- Patch [3]: [PATCH v6 03/18] tracing/remotes: Use kstrtobool for boolean tracefs files ---commit 2c1ad77f49e430730de7a438ec955b0c042628e4 Author: Vincent Donnefort [off-list ref] tracing/remotes: Use kstrtobool for boolean tracefs files Use kstrtobool in trace_remote.c where possible. This is more user-friendly as it allows a better variety of input strings.quoted
diff --git a/kernel/trace/trace_remote.c b/kernel/trace/trace_remote.c index 0384277070b9e..0e4d41a93a7ce 100644 --- a/kernel/trace/trace_remote.c +++ b/kernel/trace/trace_remote.c@@ -235,10 +235,10 @@ tracing_on_write(struct file *filp, const char __user *ubuf, size_t cnt, loff_t { struct seq_file *seq = filp->private_data; struct trace_remote *remote = seq->private; - unsigned long val; + bool val; int ret; - ret = kstrtoul_from_user(ubuf, cnt, 10, &val); + ret = kstrtobool_from_user(ubuf, cnt, &val); if (ret) return ret;[ ... ] [Severity: High] This isn't a bug introduced by this patch, but I noticed a potential regression in trace_pipe_read() when handling oversized trace events: while (trace_remote_iter_read_event(iter)) { int prev_len = iter->seq.seq.len; if (trace_remote_iter_print_event(iter)) { iter->seq.seq.len = prev_len; break; } trace_remote_iter_move(iter); } When trace_remote_iter_print_event() fails on an oversized event and returns -EOVERFLOW, the loop breaks before calling trace_remote_iter_move(). Does this leave the unformatted event in the buffer?
I will ignore that for the moment. There is no oversized event and the remote is a more privileged component than the kernel anyway.
If the event is left in the buffer and the sequence buffer is empty, trace_seq_to_user() will return -EBUSY. The code then calls ring_buffer_wait(), which would immediately return 0 because the event is still in the ring buffer. Could this cause a CPU lockup where the core infinitely reads the same oversized event and fails to format it? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260817135517.3919534-1-vdonnefort@google.com?part=3
-- Vincent