Re: [PATCH v4 3/9] ring-buffer: Fix subbuf resize race with ring buffer readers

On Wed, 12 Aug 2026 13:24:57 -0400
Steven Rostedt <[email protected]> wrote:

> 
> Hi Roman,
> 
> On Wed, 12 Aug 2026 17:44:41 +0100
> Vincent Donnefort <[email protected]> wrote:
> 
> > > [Severity: High]
> > > This is a pre-existing issue, but can this 32-bit integer capacity calculation
> > > truncate large trace buffers?
> > > 
> > > For buffers larger than 4GB, the multiplication of old_capacity and
> > > buffer->buffers[cpu]->nr_pages can exceed 32 bits. Because nr_pages is a
> > > 32-bit signed integer, the result is truncated, and the buffer is shrunk to a
> > > tiny fraction of its intended size during a resize operation.  
> > 
> > This is fixed in a later patch.
> > 
> > >   
> > > > +		nr_pages = DIV_ROUND_UP(nr_pages, rb_subbuf_capacity(buffer));
> > > >  
> > > >  		/* we need a minimum of two pages */
> > > >  		if (nr_pages < 2)  
> > > [ ... ]  
> > > > @@ -7896,7 +7941,7 @@ int ring_buffer_map_get_reader(struct trace_buffer *buffer, int cpu)
> > > >  			 * missed events, then record it there.
> > > >  			 */
> > > >  			commit = rb_page_size(reader);
> > > > -			if (buffer->subbuf_size - commit >= sizeof(missed_events)) {
> > > > +			if (rb_subbuf_capacity(buffer) - commit >= sizeof(missed_events)) {  
> > > 
> > > [Severity: High]
> > > This is a pre-existing issue, but does this create a time-of-check to
> > > time-of-use race leading to an out-of-bounds kernel memory write and
> > > VMAP flush?  
> > 
> > This is fixed in a later patch.
> > 
> 
> Is it possible to have Sashiko pull together all the patches so that it
> doesn't report bugs that are fixed later in the series? I mean, sending a
> patch series to fix a bunch of issues shouldn't trigger Sashiko telling you
> about the issues in the early patches where the fix is in that same patch
> series later on.

Agreed. Since we have to backport the fixes to stable kernels, the fixes
must be the first in the series (even if it looks like ad-hoc). We can
clean it up or enhance it later.

Thank you,

-- 
Masami Hiramatsu (Google) <[email protected]>