mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Zqiang" <qiang.zhang@linux.dev>
To: paulmck@kernel.org, "KunWu Chan" <kunwu.chan@gmail.com>
Cc: jiangshanlai@gmail.com, josh@joshtriplett.org,
	rostedt@goodmis.org, mathieu.desnoyers@efficios.com,
	rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] srcutree: Add lockdep and early-boot checks to  synchronize_srcu_atomic()
Date: Sun, 13 Sep 2026 06:21:44 +0000	[thread overview]
Message-ID: <32e952728ea1a9c25c2b56de468f43a32104b8a8@linux.dev> (raw)
In-Reply-To: <e6be6641-731c-4b21-ad4e-c05bedc388d6@paulmck-laptop>

> 
> 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 <paulmck@kernel.org> 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 <qiang.zhang@linux.dev>
> >  > Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>
> > 
> >  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.

Hi, Paul and KunWu

Should we also consider the following situations ?


idx = srcu_read_lock_atomic(srcu)

by interrupt run hardirq context:
   synchronize_rcu_atomic(srcu)

srcu_read_unlock_atomic(srcu, idx)


or:



           CPU0:                                                                  CPU1:                                           

idx = srcu_read_lock_atomic(srcu)

smp_call_function_single(CPU1, som_func, NULL, 1)
to send IPI to CPU1, and sync wait complete.
                                                                   hardirq context or ide task context:

                                                                          some_func()
                                                                          ->synchronize_rcu_atomic(srcu)  

srcu_read_unlock_atomic(srcu, idx)


Add WARN_ON(irqs_disabled()) to synchronize_rcu_atomic() ?

Any thoughts?

Thanks
Zqiang


> 
>  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	other threads:[~2026-09-13  6:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11  9:35 Kunwu Chan
2026-09-11 16:47 ` Paul E. McKenney
2026-09-12 12:37   ` KunWu Chan
2026-09-12 18:50     ` Paul E. McKenney
2026-09-13  6:21       ` Zqiang [this message]
2026-09-13 10:36         ` KunWu Chan
2026-09-13 10:23       ` KunWu Chan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32e952728ea1a9c25c2b56de468f43a32104b8a8@linux.dev \
    --to=qiang.zhang@linux.dev \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=kunwu.chan@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®