On Tue, 27 Jan 2026 15:18:05 -0800 "Paul E. McKenney" <[email protected]> wrote:
> Ah, I get it. I think. NMIs, right? > > In your source tree, line 792 of kernel/rcu/srcutree.c is this line of > code, correct? > > WARN_ON_ONCE((read_flavor != SRCU_READ_FLAVOR_NMI) && in_nmi()); > > If so, could you please try this test with the patch shown at the end > of this email? > > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c > index c469c708fdd6a..66ba6a2f83d3a 100644 > --- a/kernel/rcu/srcutree.c > +++ b/kernel/rcu/srcutree.c > @@ -789,7 +789,8 @@ void __srcu_check_read_flavor(struct srcu_struct *ssp, > int read_flavor) > struct srcu_data *sdp; > > /* NMI-unsafe use in NMI is a bad sign, as is multi-bit read_flavor > values. */ > - WARN_ON_ONCE((read_flavor != SRCU_READ_FLAVOR_NMI) && in_nmi()); > + WARN_ON_ONCE(read_flavor != SRCU_READ_FLAVOR_NMI && > + read_flavor != SRCU_READ_FLAVOR_FAST && in_nmi()); > WARN_ON_ONCE(read_flavor & (read_flavor - 1)); > > sdp = raw_cpu_ptr(ssp->sda); It appears to fix the issue. Tested-by: Steven Rostedt (Google) <[email protected]> Care to send a formal patch, and I'll add it before the patch that causes issues. Thanks, -- Steve
