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

[Vincent Donnefort <vdonnefort@google.com>]

On Fri, Aug 07, 2026 at 10:45:26AM -0400, Steven Rostedt wrote:
> On Fri, 7 Aug 2026 10:43:12 +0100
> Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> > On Fri, Aug 07, 2026 at 09:14:26AM +0100, Vincent Donnefort wrote:
> > > On Fri, Aug 07, 2026 at 11:18:08AM +0900, Masami Hiramatsu wrote:  
> > > > On Thu,  6 Aug 2026 22:13:01 +0100
> > > > Vincent Donnefort <vdonnefort@google.com> wrote:
> > > >   
> > > > > Dynamically resizing a persistent ring buffer is not possible. Disable
> > > > > the feature.  
> > > > 
> > > > Is it true? Of course there is meaningless to resize the persistent
> > > > ring buffer (because it makes the buffer none-persistent), we are currently
> > > > allows user to resize it (like for resizing unused persistent ring buffer)  
> > > 
> > > __rb_allocate_pages() in ring_buffer_resize() would call for a persistent buffer
> > > rb_range_buffer(), which IIUC, is just reusing the same ring buffer pages as the
> > > one already in the persistent buffer.  
> > 
> > I have just tried and if reducing the size works, increasing fails in both
> > rb_set_head_page() and rb_insert_pages() with a warning, which I believe is
> > expected.
> > 
> > We could improve that, but it feels like it is a lot of work for a meaningless
> > feature which we should just disable?
> 
> Resizing a persistent ring buffer to a smaller size may be allowed, but I
> see no point in increasing the size. Making it smaller should allow us to
> give back a portion of the persistent ring buffer for general usage.
> 
> -- Steve

While I see the appeal to reclaim that memory, I don't think we have any good
interface for that. There is no nice way to get the list of pages that have been
freed and we have no control over what part of the ring-buffer is removed.

Also, as this memory is from a reserved-range, is there really a way to re-inject
it into the buddy allocator?

Perhaps what would make sense for resizing would be to support a CMA pool as a
persistent buffer?

-- 
Vincent