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]>
