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.

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

Reply via email to