On Sun, 23 Aug 2026 21:09:05 +0100 Vincent Donnefort <[email protected]> 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
