On Mon, Aug 17, 2026 at 02:11:20PM +0000, [email protected] wrote: > 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 <[email protected]> > > 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. > > > 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/[email protected]?part=3 -- Vincent
