Agreed. I’ll add an explicit resize-in-progress flag, set it around
the order transition, and make the external read-page
allocation/free/read paths reject work while it is set. I’ll check the
flag under the locks that serialize each path so it cannot race the
transition, then compile and test the resulting v2.

On Tue, 30 Jun 2026 17:16:03 -0400, Steven Rostedt [off-list ref] wrote:

On Tue, 30 Jun 2026 13:45:05 -0700
Yousef Alhouseen [off-list ref] wrote:

quoted

One issue turned up while checking the suggested locking:
ring_buffer_subbuf_order_set() writes buffer->subbuf_order before
taking reader_lock and never takes cpu_buffer->lock. An allocator can
therefore take cpu_buffer->lock after the new order is published but
before resize clears the old-order free_page, tag that old page with
the new order, and return it.

I can keep the allocations outside buffer->mutex and hold the mutex
only while snapshotting subbuf_order and taking or returning
free_page. That removes allocation from the critical section and
serializes the order/free-page pair with resize. Would you prefer
that, or should free_page and the order transition be synchronized
another way?

Nothing should be reading when the subbuf_order is being updated. Let's add
a flag to state that it's being updated, and make all reads simply fail
during that time.

-- Steve