Re: [PATCH 1/6] ring-buffer: Prevent resizing of persistent ring buffer

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 10 Aug 2026 09:56:53 +0100
Vincent Donnefort <vdonnefort@google.com> wrote:

> > > 
> > > What would need to be done is:
> > > 
> > >   1. calculate the new size needed to accommodate all the CPU buffers.
> > >   2. Split them up within the new size region.
> > >   3. Then free the remaining pages.
> > > 
> > > Obviously, access to the buffer from readers and writers will need to be
> > > prohibited while this is happening.  
> 
> That would mean losing all the data on the buffer? Actually the trace_remote
> needs to teardown the whole buffer before the size is modified. Perhaps if
> something similar is done for the persistent buffer, trace_remote could benefit.

Yes it would remove all data in the buffer. If you are going to resize the
buffer, you need to be OK with loss of data. It's not going to be a gentle
operation.

> 
> > 
> > Hmm, I think we also need to record the size of persistent ring buffer at
> > initialization. The buffer size (number of pages are calculated by the
> > size of reserved memory, which is defined in the kernel cmdline.  

Oh right. If we do the change, it needs to be stored because of the checks
done at boot up. It checks to make sure that the size on boot up is the
same as when it was running. If we remove pages, that needs to be passed to
the meta data so that on reboot it can detect that.

> 
> Could we store in ring_buffer_cpu_meta::buffers that the page is gone and must
> be skipped to re-create the ring-buffer?

Not just skipped, but the amount "saved" will be different.

Now we need to know that the amount of the ring buffer is different than
the kernel command line. What I would have is this:

1. Bootup wit persistent ring buffer at size X.
2. At run time, shrink buffer to size Y where Y < X
2a. Rewrite buffer with new total size and divvy up the per CPU buffers
2b. Write the new size in the cpu meta data
3. Start tracing
4. Crash/reboot
5. Check meta data checksum, and if match and size is different, divvy up by given size.
5a. Record the currently saved size.
6. Show size as "original cmdline size" (why? see next step)
7. Start tracing
7a.  Rewrite buffer with the origin cmdline size
7b.  Start actual tracing

That is, the resize is only applicable for the boot where the resize
happened. The output of the resize will still be visible, but the buffers
will go back to the original cmdline size as soon as tracing begins again.

If the user resizes again, then jump back to 2a.

The resize is only to allow a user to reclaim persistent buffer memory if
they do not think they need to save as much after boot up.

-- Steve