Re: [PATCH] ring-buffer: Do not allow reader to see unfinished moved head

[Steven Rostedt <rostedt@goodmis.org>]

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

> Steve,
> 
> Thank for the patch,
> 
> On Mon, Nov 09, 2026 at 08:39:43AM +0000, sashiko-bot@kernel.org wrote:
> > > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > > index e760d2fe386fb..cf9e0dc10c88f 100644
> > > --- a/kernel/trace/ring_buffer.c
> > > +++ b/kernel/trace/ring_buffer.c
> > > @@ -1494,7 +1494,13 @@ rb_set_head_page(struct ring_buffer_per_cpu *cpu_buffer)
> > >  	if (RB_WARN_ON(cpu_buffer, rb_list_head(list->prev->next) != list))
> > >  		return NULL;
> > >  
> > > -	page = head = cpu_buffer->head_page;
> > > +	/*
> > > +	 * Make sure that the start of the search of the head_page does not
> > > +	 * start between the writer adding the UPDATE and the new HEAD that it
> > > +	 * moves forward.
> > > +	 */
> > > +	/* Sync with the writer moving the HEAD in rb_handle_head_page() */
> > > +	page = head = smp_load_acquire(&cpu_buffer->head_page);  
> > 
> > [Severity: Medium]
> > Can the reader's non-atomic update of cpu_buffer->head_page in
> > __rb_get_reader_page() race with the writer's new store in
> > rb_handle_head_page() and advance cpu_buffer->head_page past the sub-buffer
> > marked for update?  
> 
> I've asked my robot to test this case, and it was still able to
> reproduce the race, even with this patch.


Are you still testing with the minimum of 7K? Can you up it to can you
echo 11 into buffer_size_kb to see if it is an issue with three
sub-buffers?

I just want to know if it you are catching issues with something that
looks like this:

                             tail
                              v
   +--HEAD--> subbuf ----> subbuf --+
   |                                |
   +--------------------------------+

Two subbufs should still be fixed but I want to make sure I'm not
looking at two different bugs.

-- Steve