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

On Mon, Aug 24, 2026 at 10:53:15AM -0400, Steven Rostedt wrote:

On Sun, 23 Aug 2026 21:09:05 +0100
Vincent Donnefort [off-list ref] wrote:

quoted

quoted

quoted

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

quoted

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.

quoted

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