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

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.

Thanks,

-- Steve