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 [off-list ref] wrote:

Hi Roman,

On Wed, 12 Aug 2026 17:44:41 +0100
Vincent Donnefort [off-list ref] wrote:

quoted

quoted

[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.

quoted

quoted

+		nr_pages = DIV_ROUND_UP(nr_pages, rb_subbuf_capacity(buffer));
 
 		/* we need a minimum of two pages */
 		if (nr_pages < 2)  

[ ... ]  

quoted

@@ -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) [off-list ref]