Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] tracing: trace_remote_do_dmesg() stalls iterator when
!CONFIG_PRINTK
--
commit 8ec4000ae15e5140e201a48a2cd1db29b0828760
Author: Vincent Donnefort [off-list ref]
tracing/remotes: Add dmesg tracefs file
This commit adds a dmesg tracefs file to trace remotes that redirects
remote trace events to dmesg when enabled.
quoted hunk ↗ jump to hunk
diff --git a/kernel/trace/trace_remote.c b/kernel/trace/trace_remote.c
index 08a89b7315c3c..3dbb4912dbd6d 100644
--- a/kernel/trace/trace_remote.c
+++ b/kernel/trace/trace_remote.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -883,6 +909,87 @@ static const struct file_operations trace_fops = {
.release = trace_release,
};
+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;
+
+ trace_remote_iter_move(iter);
[Severity: Low]
Does this stall the iterator when CONFIG_PRINTK is disabled?
With !CONFIG_PRINTK, the _printk() stub returns 0, so the loop breaks
before trace_remote_iter_move() consumes the peeked event. Enabling the
dmesg file then keeps poll_work running and pins the remote trace buffer
open while repeatedly peeking the same first event without making progress.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106180657.2460376-1-vdonnefort@google.com?part=8