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]>
