On Sun, Sep 13, 2026 at 2:50 AM Paul E. McKenney <[email protected]> wrote: > > On Sat, Sep 12, 2026 at 08:37:33PM +0800, KunWu Chan wrote: > > 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. > > Sounds good! > > Perhaps you and Zqiang can work together on this. Co-developed-by, > for example.
Thanks, Paul. I'am happy to do that. @Zqiang, your suggestions on the additional lockdep cases got me started, and these are now incorporated as testtypes 4 and 5. Paul's observation that synchronize_srcu_atomic() can legitimately be called from a normal RCU read-side critical section led to an additional regression test (testtype 6). In particular, testtype 6 verifies that calling synchronize_srcu_atomic() from within rcu_read_lock()/rcu_read_unlock() does not produce a false-positive lockdep warning. The atomic SRCU same-type nesting cases are covered by testtype 4 and are expected to trigger the RCU_LOCKDEP_WARN() in synchronize_srcu_atomic(). The changes are in rcutorture.c and srcu_lockdep.sh; torture.sh does not need to change. The testing changes are basically complete. @Zqiang, I'm happy to add: Co-developed-by: Zqiang <[email protected]> Signed-off-by: Zqiang <[email protected]> if you're OK with that. Thanks, Kunwu > > Thanx, Paul > > > 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 > > > >
