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

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 23 Aug 2026 21:09:05 +0100
Vincent Donnefort <vdonnefort@google.com> wrote:

> > > [Severity: High]
> > > If ring_buffer_read_page() returns -EAGAIN because the subbuffer order was
> > > updated but cpu_buffer->reader_page->order hasn't been updated yet, this
> > > branches back to the again label.
> > > 
> > > Since the loop does not yield the CPU or call cond_resched(), could this cause
> > > a hard lockup if the reader and the resize thread are on the same CPU?  
> > 
> > Hmm, this looks legit. We should at least have a way to break out if it
> > loops too many times.  
> 
> Can this happen only on !CONFIG_PREEMPT systems?

It can happen with RT tasks as they don't yield. If this task is of higher
priority than the one resizing, then it will loop forever even with a
cond_resched().

> 
> I can add a cond_resched() here though, I believe that would make sense: if an
> order modification is pending, writing is disabled anyway and we are about to
> loose the stored events.

For RT tasks, cond_resched() wouldn't be enough.

> 
> Additionally I can reduce the window where buffer::subbuf_order differs from the
> reader page order by adding an "order" argument to __rb_allocate_pages() and
> only set buffer::subbuf_order later in ring_buffer_subbuf_order_set().

I'm wondering if we even care if data_page->order != cpu_buffer->reader_page->order
and should change it to being a force copy instead.

If the reader_page is bigger than the dpage, and only copy what the dpage
can hold. It would also update the read value of the reader_page which
would allow another copy to get the rest. If the data page is bigger, then
just copy everything.

It's not like this will happen often.

-- Steve