Re: [PATCH v4 2/9] ring-buffer: Hold cpu_buffer::lock when resizing a subbuf

On Wed, 12 Aug 2026 15:46:58 +0000
[email protected] wrote:

> [Severity: High]
> This is also a pre-existing issue, but does adding this unconditional
> arch_spin_lock() widen an NMI deadlock window?
> 
> If an NMI (such as a watchdog or an Oops triggering ftrace_dump_on_oops)
> fires on the same CPU while this lock is held, the NMI handler may attempt
> to read the ring buffer.
> 
> The read path via __rb_get_reader_page() unconditionally acquires the same
> cpu_buffer->lock using arch_spin_lock() without an NMI-safe trylock
> fallback.
> 
> Because the interrupted context holds the lock, will the NMI handler spin
> forever, causing a hard lockup?

Ah, just a comment. The reader side is using rb_reader_lock(), which checks
in_nmi() and use trylock. Since this ring_buffer_subbuf_order_set() is
never be used from NMI, we don't need to care about this.

Thanks,


-- 
Masami Hiramatsu (Google) <[email protected]>