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
