Thread (28 messages) flat view 28 messages, 2 authors, 2d ago

Re: [PATCH v6 03/18] tracing/remotes: Use kstrtobool for boolean tracefs files

From: sashiko-bot@kernel.org
Date: 2026-08-17 14:11:21

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 hunk ↗ jump to hunk
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?

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help