From: Vincent Donnefort <vdonnefort@google.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: mhiramat@kernel.org, linux-trace-kernel@vger.kernel.org,
mathieu.desnoyers@efficios.com, kernel-team@android.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 3/4] ring-buffer: Cap static ring buffer nr_pages
Date: Fri, 4 Sep 2026 14:04:40 +0100 [thread overview]
Message-ID: <aprB6OE1juuopC7q@google.com> (raw)
In-Reply-To: <20260903125621.36cd33b8@gandalf.local.home>
On Thu, Sep 03, 2026 at 12:56:21PM -0400, Steven Rostedt wrote:
> On Tue, 1 Sep 2026 16:54:44 +0100
> Vincent Donnefort <vdonnefort@google.com> wrote:
>
> > Static ring buffers (i.e. persistent, user-mapped and remote) rely on
> > the bpage::id field. The number of pages for those ring buffers must fit
> > into that variable. Enforce this limit on ring buffer creation or
> > user-mapping.
> >
> > While at it, make buffer_page::id 31 bits. This does not change the
> > struct buffer_page size.
>
> Let's not add that change to this patch. Especially since this has a fixes
> tag to it. That change has nothing to do with the fix.
>
> The reason I had it as 30 to begin with was to reserve a bit in case I
> found another reason for it. If 1<<30 is too small for the number of boot
> buffer pages, we can always up in another order in the future.
>
> >
> > Fixes: be68d63a139b ("ring-buffer: Add ring_buffer_alloc_range()")
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> >
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index 28dd76edfecf..c4260d6ecdfc 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -350,7 +350,7 @@ struct buffer_page {
> > local_t entries; /* entries on this page */
> > unsigned long real_end; /* real end of data */
> > unsigned order; /* order of the page */
> > - u32 id:30; /* ID for external mapping */
> > + u32 id:31; /* ID for external mapping */
> > u32 range:1; /* Mapped via a range */
> > struct buffer_data_page *page; /* Actual data page */
> > };
> > @@ -657,6 +657,15 @@ static bool rb_is_static(struct ring_buffer_per_cpu *cpu_buffer)
> > return cpu_buffer->user_mapped || cpu_buffer->remote || cpu_buffer->ring_meta;
> > }
> >
> > +static unsigned long rb_static_max_pages(void)
> > +{
> > + /*
> > + * Static ring buffers are using bpage::id and must account for the
> > + * reader page.
> > + */
> > + return (1UL << 31) - 1;
> > +}
> > +
> > struct ring_buffer_iter {
> > struct ring_buffer_per_cpu *cpu_buffer;
> > unsigned long head;
> > @@ -2842,6 +2851,10 @@ static struct trace_buffer *alloc_buffer(unsigned long size, unsigned flags,
> > */
> > nr_pages = (size - sizeof(struct ring_buffer_cpu_meta)) /
> > (subbuf_size + sizeof(int));
> > +
> > + if (nr_pages > rb_static_max_pages())
> > + goto fail_free_buffers;
> > +
>
> If you want to add something, we could add to the beginning of this
> function:
>
> /* Prevent ridiculously small sizes */
> if (size < PAGE_SIZE)
> return NULL;
>
> to shut up Sashiko about overflows :-p
>
> -- Steve
tracer_alloc_buffers() uses size of 1 for non-expanded buffers.
I'll test size just before
nr_pages = (size - sizeof(struct ring_buffer_cpu_meta)) /
(subbuf_size + sizeof(int));
>
>
>
> > /* Need at least two pages plus the reader page */
> > if (nr_pages < 3)
> > goto fail_free_buffers;
> > @@ -2874,6 +2887,10 @@ static struct trace_buffer *alloc_buffer(unsigned long size, unsigned flags,
> > /* The writer is remote. This ring-buffer is read-only */
> > atomic_inc(&buffer->record_disabled);
> > nr_pages = desc->nr_page_va - 1;
> > +
> > + if (nr_pages > rb_static_max_pages())
> > + goto fail_free_buffers;
> > +
> > if (nr_pages < 2)
> > goto fail_free_buffers;
> > } else {
> > @@ -7836,6 +7853,9 @@ int ring_buffer_map(struct trace_buffer *buffer, int cpu,
> > /* prevent another thread from changing buffer/sub-buffer sizes */
> > guard(mutex)(&buffer->mutex);
> >
> > + if (cpu_buffer->nr_pages > rb_static_max_pages())
> > + return -E2BIG;
> > +
> > err = rb_alloc_meta_page(cpu_buffer);
> > if (err)
> > return err;
>
next prev parent reply other threads:[~2026-09-04 13:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 15:54 [PATCH v9 0/4] ring-buffer: Fixes for subbuf resizing and persistent buffers Vincent Donnefort
2026-09-01 15:54 ` [PATCH v9 1/4] ring-buffer: Allow splice reads on static buffers Vincent Donnefort
2026-09-03 18:26 ` Steven Rostedt
2026-09-01 15:54 ` [PATCH v9 2/4] tracing: Fix subbuf resize races with trace_pipe_raw readers Vincent Donnefort
2026-09-03 15:48 ` Steven Rostedt
2026-09-03 17:27 ` Vincent Donnefort
2026-09-01 15:54 ` [PATCH v9 3/4] ring-buffer: Cap static ring buffer nr_pages Vincent Donnefort
2026-09-01 16:35 ` sashiko-bot
2026-09-03 16:56 ` Steven Rostedt
2026-09-03 17:06 ` Vincent Donnefort
2026-09-03 17:33 ` Steven Rostedt
2026-09-04 13:04 ` Vincent Donnefort [this message]
2026-09-04 14:02 ` Steven Rostedt
2026-09-01 15:54 ` [PATCH v9 4/4] ring-buffer: Prevent truncation of nr_pages / nr_subbufs Vincent Donnefort
2026-09-01 16:48 ` sashiko-bot
2026-09-03 17:23 ` Steven Rostedt
2026-09-03 17:16 ` Steven Rostedt
2026-09-03 17:37 ` Vincent Donnefort
2026-09-03 18:17 ` Steven Rostedt
2026-09-03 14:31 ` [PATCH v9 0/4] ring-buffer: Fixes for subbuf resizing and persistent buffers Steven Rostedt
2026-09-03 15:19 ` Vincent Donnefort
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aprB6OE1juuopC7q@google.com \
--to=vdonnefort@google.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox