On Sat, Sep 12, 2026 at 12:47 AM Paul E. McKenney <[email protected]> wrote: > > On Fri, Sep 11, 2026 at 05:35:15PM +0800, Kunwu Chan wrote: > > Add the lockdep annotation, same-type SRCU nesting warning, and > > early-boot check used by __synchronize_srcu(). > > > > Suggested-by: Zqiang <[email protected]> > > Signed-off-by: Kunwu Chan <[email protected]> > > Queued for review and testing, thank you both! > > Interestingly enough, it is now the case that there is a grace-period > wait that can be placed in a normal RCU read-side critical section. > Does this mean that we should also adjust the --do-srcu-lockdep testing > in tools/testing/selftests/rcutorture/bin/torture.sh?
Thanks, Paul. Good point. I’ll check the current `--do-srcu-lockdep` coverage, including the case where `synchronize_srcu_atomic()` is called from a normal RCU read-side critical section, and follow up with the necessary torture testing changes. Thanks, Kunwu > > Thanx, Paul > > > --- > > kernel/rcu/srcutree.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c > > index 6a9c432a3bd0..6c729e805fb3 100644 > > --- a/kernel/rcu/srcutree.c > > +++ b/kernel/rcu/srcutree.c > > @@ -2123,6 +2123,14 @@ void synchronize_srcu_atomic(struct srcu_struct *ssp) > > unsigned long rdm0, rdm1; > > unsigned long unlocks0, unlocks1; > > > > + srcu_lock_sync(&ssp->dep_map); > > + > > + RCU_LOCKDEP_WARN(lockdep_is_held(ssp), > > + "Illegal synchronize_srcu_atomic() in same-type SRCU > > read-side critical section"); > > + > > + if (rcu_scheduler_active == RCU_SCHEDULER_INACTIVE) > > + return; > > + > > // Initialize. Either init_srcu_struct() was invoked or > > // DEFINE_SRCU() or similar was used. Therefore, no allocation > > // will be done here. > > -- > > 2.43.0 > >
