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: Thu, 3 Sep 2026 18:06:51 +0100 [thread overview]
Message-ID: <apmpK_QncDwqxE2B@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.
ack
>
> >
> > 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
Yeah, I wasn't sure... It's so pedantic, we have no user with a small size :-(
But that would make sense to fold that into this patch, right?
>
> -- Steve
>
>
>
> > /* 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-03 17:06 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 [this message]
2026-09-03 17:33 ` Steven Rostedt
2026-09-04 13:04 ` Vincent Donnefort
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=apmpK_QncDwqxE2B@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.