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

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 9 Nov 2026 05:10:37 -0800
Breno Leitao <leitao@debian.org> wrote:

> Hello Steven,
> 
> On Thu, Nov 05, 2026 at 03:57:29PM -0500, Steven Rostedt wrote:
> > Can you try this?
> > 
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index c64e001c3fc0..f0bb2d23d818 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -3721,6 +3721,14 @@ rb_handle_head_page(struct ring_buffer_per_cpu *cpu_buffer,
> >  		local_sub(rb_page_commit(next_page), &cpu_buffer->entries_bytes);
> >  		local_inc(&cpu_buffer->pages_lost);
> >  
> > +		/*
> > +		 * To prevent a stale head_page from being between
> > +		 * the UPDATE and new HEAD pages, set it here to have
> > +		 * the reader check always find the update before
> > +		 * finding the HEAD page.
> > +		 */
> > +		cpu_buffer->head_page = next_page;
> > +
> >  		if (cpu_buffer->ring_meta)
> >  			rb_update_meta_head(cpu_buffer, next_page);
> >  		/*
> > 
> > We may need to add memory barriers here, but for now, I think this could
> > fix it. As it should prevent the search from ever starting in between the
> > two heads.  
> 
> This seems to be racy as well. Sashiko found the race, and it can be
> reproduced by adding some delays in the code.

Yeah, I'm currently traveling and didn't have time to do a deep dive
into a real fix and decided to be lazy and post the patch and see what
sashiko found ;-)

Thanks for verifying the issue with this "fix" that Sashiko pointed out.

I need to spend a bit of time looking deeper into it to come up with a
real solution.

-- Steve