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

[email protected]
Newsgroups org.kernel.vger.linux-trace-kernel
Message-ID <[email protected]>
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?

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.