Re: [PATCH v8 1/3] tracing: Fix subbuf resize races with trace_pipe_raw readers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ring_buffer_read_page() incorrectly returns -1 for splice_read requests on subbuf order mismatch
--

commit c4d6ee6f55f23c8ec6da6f812ec3b722b2b7f6b6
Author: Vincent Donnefort <vdonnefort@google.com>

tracing: Fix subbuf resize races with trace_pipe_raw readers

This commit modifies ring_buffer_alloc_read_page() and
ring_buffer_read_page() to handle dynamic resizing of trace ring
buffers, allowing readers to avoid stale size values. It introduces
a manual data copy fallback in ring_buffer_read_page() when the
subbuffer orders do not match.

> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
[ ... ]
> @@ -7183,7 +7218,8 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
>  	 */
>  	if (read || (len < (size - read)) ||
>  	    cpu_buffer->reader_page == cpu_buffer->commit_page ||
> -	    rb_is_static(cpu_buffer)) {
> +	    rb_is_static(cpu_buffer) ||
> +	    data_page->order != reader->order) {
>  		struct buffer_data_page *rpage = cpu_buffer->reader_page->page;
>  		unsigned int rpos = read;
>  		unsigned int pos = 0;

[Severity: High]
Does this new condition break splice reads when the buffer order changes?

When tracing_buffers_splice_read() allocates a read page with the new order
and calls ring_buffer_read_page() with full=1, it will now enter this manual
copy block because the subbuffer orders no longer match.

However, just a few lines down inside this block in ring_buffer_read_page(),
there is the following check:

        if (full &&
            (!read || (len < (size - read)) ||
             cpu_buffer->reader_page == cpu_buffer->commit_page))
                return -1;

Since the reader page typically hasn't been partially read yet (read == 0),
and full == 1 from splice, this check evaluates to true and immediately
returns -1 instead of copying the data.

Because tracing_buffers_splice_read() loops and ultimately returns -EAGAIN
on failure, will this cause an infinite loop of -EAGAIN for userspace tools
trying to read across buffer resizes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826094528.3738023-1-vdonnefort@google.com?part=1