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 <[email protected]> wrote: > On Tue, 30 Jun 2026 13:45:05 -0700 > Yousef Alhouseen <[email protected]> wrote: > > > 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
