Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] tracing: infinite polling loop when pr_info returns 0 --
commit 84b99572dcf19a3615c7c7c55a76f23735f8f5c9 Author: Vincent Donnefort <[email protected]> tracing/remotes: Add dmesg tracefs file This commit introduces a dmesg tracefs file for the tracing remotes subsystem. When enabled, it redirects all events to dmesg, acting similarly to tp_printk. > diff --git a/kernel/trace/trace_remote.c b/kernel/trace/trace_remote.c > --- a/kernel/trace/trace_remote.c > +++ b/kernel/trace/trace_remote.c [ ... ] > @@ -883,6 +909,87 @@ static const struct file_operations trace_fops = { > +static bool trace_remote_do_dmesg(struct trace_remote *remote) > +{ > + struct trace_remote_iterator *iter = smp_load_acquire(&remote->dmesg); > + unsigned int max_events = 1000; > + > + if (!iter) > + return false; > + > + trace_remote_iter_read_start(iter); > + > + while (trace_remote_iter_read_event(iter)) { > + trace_seq_init(&iter->seq); > + > + trace_remote_iter_print_event(iter); > + trace_seq_putc(&iter->seq, 0); > + if (!pr_info("%s", seq_buf_str(&iter->seq.seq))) > + break; [Severity: Medium] What happens here in trace_remote_do_dmesg() if the kernel is compiled with CONFIG_PRINTK disabled? When CONFIG_PRINTK=n, the pr_info() macro unconditionally returns 0. If pr_info() returns 0, this loop breaks immediately before calling trace_remote_iter_move() to consume the event. Could this result in the same event being infinitely polled without making progress, wedging the remote trace integration? > + > + trace_remote_iter_move(iter); > + > + if (!(--max_events)) > + break; > + } > + > + trace_remote_iter_read_finished(iter); > + > + return !max_events; > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8
