Re: [PATCH] ring-buffer: Fix false warning in ring_buffer_map_get_reader()

On Fri, Sep 18, 2026 at 02:34:25PM +0000, syzbot wrote:

From: Krystian Kaniewski <redacted>

In ring_buffer_map_get_reader(), an unconditional WARN_ON(!reader) is
triggered when rb_get_reader_page() returns NULL:

WARNING: CPU: 1 PID: 5906 at kernel/trace/ring_buffer.c:7998
ring_buffer_map_get_reader+0x940/0x9d0
CPU: 1 UID: 0 PID: 5906 Comm: task Not tainted
RIP: 0010:ring_buffer_map_get_reader+0x940/0x9d0
kernel/trace/ring_buffer.c:7998
Call Trace:
 <TASK>
 tracing_buffers_ioctl+0x258/0x300 kernel/trace/trace.c:7381
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 </TASK>

This warning is triggered due to a race between a writer committing events
and a reader mapping the ring buffer via TRACE_MMAP_IOCTL_GET_READER. When
a writer commits an event in rb_set_commit_to_write(), it advances
cpu_buffer->commit_page to cpu_buffer->tail_page in its first loop before
updating the commit counter (commit_page->page->commit) in the second loop.
If a reader invokes ring_buffer_map_get_reader() at this moment, the
initial check cpu_buffer->reader_page == cpu_buffer->commit_page is false,
and it calls rb_get_reader_page(). Inside __rb_get_reader_page(), the
reader swaps reader_page with the head page (which is the new commit_page).
Because the writer has not yet updated the commit count on the new page,
rb_page_size() is zero and reader_page->read < rb_page_size() evaluates to
false. __rb_get_reader_page() then checks if cpu_buffer->commit_page ==
cpu_buffer->reader_page. Since both now point to the swapped page, the
condition evaluates to true and rb_get_reader_page() legitimately returns
NULL to indicate the reader caught up to the writer.

This seems to make the check above reader_page == commit_page redundant. Doesn't
it?

Furthermore, rb_get_reader_page() can legitimately return NULL when there
is no data to read. Re-checking mutable writer state such as

We are checking rb_per_cpu_empty() with the reader_lock held few lines above. I
don't believe we expect NULL here for that reason.

-- 
Vincent