Re: [PATCH v3] tracing: ring-buffer: serialize shrink with NMI readers

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 11 Nov 2026 17:43:01 +0800
Haoli Zhang <26031212468@stu.xidian.edu.cn> wrote:

> The syzbot report shows a use-after-free in rb_is_reader_page(), reached
> from rb_move_tail(), with the freed page released by rb_remove_pages().
> Source inspection suggests that a detached reader page can retain a link
> into the range removed during a shrink. This patch addresses that possible
> stale-link path and coordinates NMI readers with page removal.
> 
> When an NMI reader cannot acquire reader_lock, rb_reader_lock() falls back

What NMI readers?

The only time NMI reads the ring buffer is on a crash

> to reading the ring buffer without the lock. Gate lockless NMI readers

Yes, it reads without a lock because the system crashed and the NMI
handler is doing a *BEST EFFORT* to read the ring buffer to see if it
can produce output that tells us why the system crashed.

> while rb_remove_pages() removes pages. Drain readers that entered before
> the gate before changing the page list. New NMI readers that cannot acquire
> reader_lock while the gate is closed skip that CPU. Readers that acquire
> reader_lock remain serialized by it. The drain loop calls cond_resched()
> while waiting for readers to exit.
> 
> During shrink, redirect reader_page->list.prev if it points to a page being
> removed. Also detect a stale reader_page->list.next and redirect it after
> reconnecting the ring to the surviving successor link, including the
> transferred head flag.
> 
> When an NMI reader skips a CPU while resize_in_progress is set, treat that
> CPU buffer as empty in the empty-query helpers. This lets ftrace_dump_one()
> make progress instead of retrying forever when peek/consume also skip the buffer. Entries on a skipped CPU may be omitted from the dump.
> Clear event on every consume retry. Cache whether it is padding
> before unlocking. This avoids reading event fields after unlock.
> Clear timestamps on skipped peek and consume operations.
> 
> The NMI fallback increment of record_disabled is intentionally retained.
> The existing fallback comment says an unlocked NMI read may corrupt the
> buffer and that recording must remain disabled afterward; the existing
> unlock path does not undo that disable. The nmi_readers counter is separate
> and tracks only the temporary lifetime of a lockless NMI read.
> 
> Fixes: 83f40318dab0 ("ring-buffer: Make removal of ring buffer pages atomic")

This is not a fix.

> Reported-by: syzbot+37e1793bdb0061ea3a47@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=37e1793bdb0061ea3a47

No the bug report has NOTHING TO DO WITH NMIs!


> Co-developed-by: Jinning Zhang <25031212117@stu.xidian.edu.cn>
> Signed-off-by: Jinning Zhang <25031212117@stu.xidian.edu.cn>
> Co-developed-by: Bin Yu <byu@xidian.edu.cn>
> Signed-off-by: Bin Yu <byu@xidian.edu.cn>
> Signed-off-by: Haoli Zhang <26031212468@stu.xidian.edu.cn>
> 
> ---
> v3:

I'm not adding this complexity to handle the best effort case of an NMI
reading the ring buffer during a crash.

NAK!

-- Steve