Re: [PATCH v2] ring-buffer: Handle a reader taking the new head in rb_handle_head_page()

[Vincent Donnefort <vdonnefort@google.com>]

On Thu, Nov 12, 2026 at 06:14:23AM -0500, Steven Rostedt wrote:
> On Wed, 11 Nov 2026 13:32:13 +0000
> Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> > Yes, now I spent more time on it, I believe it makes sense. I looked at what we
> > could do and I'm trying to use a temporary RB_PAGE_HEAD | RB_PAGE_UPDATE. This
> > link flag is then only converted to RB_PAGE_HEAD by the outer writer. I believe
> > this would fix the race entirely... However that means the reader spins as long
> > as the buffer writing is interrupted, which I admit is far from ideal.
> 
> But it is only interrupted by interrupts ;-) which should be fast.
> 
> No different than waiting for a spin lock whose owner got interrupted
> by an interrupt.
> 
> -- Steve

Yes hopefully it shouldn't be too terrible. But, as we disable interrupts on the
CPU doing the read, it's sort of propagating the latency from one CPU to the
other, which I believe wasn't the case so far, since an interrupt could
"release" the reader by setting HEAD.

Perhaps I could propagate a -EAGAIN back to ring_buffer_consume to temporarily
release rb_reader_lock() and try again there? But that would be a bit intrusive
as most of the functions are returning a ring_buffer_event * and not an int.

The attempt is here [1]. Sashiko had something to say but I haven't processed
yet how bad it is.

[1] https://lore.kernel.org/all/20261111160624.1294946-1-vdonnefort@google.com/

-- 
Vincent