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

[Vincent Donnefort <vdonnefort@google.com>]

On Mon, Aug 24, 2026 at 10:53:15AM -0400, Steven Rostedt wrote:
> 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().

Ha yes of course!

> 
> > 
> > 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


That sounds interesting... that would get rid of the -EAGAIN. Let me try.

Do you think it is still worth to reduce the window of discrepency between
buffer->subbuf_order and buffer_page->order?

-- 
Vincent