Re: [PATCH] rcu: Use an intermediate irq_work to start process_srcu()

[Boqun Feng <boqun@kernel.org>]

On Sun, Mar 22, 2026 at 12:47:41PM -0700, Paul E. McKenney wrote:
> On Sun, Mar 22, 2026 at 11:17:27AM -0700, Boqun Feng wrote:
> > On Sun, Mar 22, 2026 at 10:44:58AM -0700, Paul E. McKenney wrote:
> > [...]
> > > > > > > Longer term, shouldn't lockdep take into account the fact that on !SMP,
> > > > > > > the disabling of preemption (or interrupts or...) is essentially the same
> > > > > > > as acquiring a global lock?  This means that only one task at a time can
> > > > > > > be acquiring a raw spinlock on !SMP, so that the order of acquisition
> > > > > > > of raw spinlocks on !SMP is irrelevant?  (Aside from self-deadlocking
> > > > > > > double acquisitions, perhaps.)  In other words, shouldn't lockdep leave
> > > > > > > raw spinlocks out of lockdep's cycle-detection data structure?
> > > > > > 
> > > > > > Lockdep doesn't know whether a code path is UP-only, so it'll apply the
> > > > > > general locking rule to check. Similar as lockdep still detect
> > > > > > PREEMPT_RT locking issue for !PREEMPT_RT kernel. Maybe we can add a
> > > > > > separate kconfig to narrow down lockdep detection for UP-only if UP=y.
> > > > > 
> > > > > But lockdep *does* know when it is running in a CONFIG_SMP=n kernel,
> > > > > correct?  In which case all the code paths are UP-only.
> > > > 
> > > > Why? UP and SMP can share the same code path, no? Just because lockdep
> > > > is running in UP and see a code path, doesn't mean that code path is
> > > > UP-only, right? What I was trying to say is Lockdep detects generel
> > > > locking rule violation, so even when it's running in UP kernel, it'll
> > > > use rules that SMP uses.
> > > 
> > > I know that this is what lockdep is doing.  I am instead saying that
> > > what lockdep is doing is not a good thing.  ;-)
> > 
> > I see.
> > 
> > > > > The situation with CONFIG_PREEMPT_RT=y is quite different: The motivation
> > > > > was for people running lockdep on CONFIG_PREEMPT_RT=n kernels to
> > > > > detect and fix locking issues that would otherwise only show up in
> > > > > CONFIG_PREEMPT_RT=y kernels.
> > > > 
> > > > I'm not sure how it's different than people wanted to detect SMP=y
> > > > locking issues when running UP kernel. Of course, I didn't know whether
> > > > that's the intention because I wasn't there ;-)
> > > 
> > > It is very different.
> > > 
> > > There were very few people developing and running PREEMPT_RT, so it
> > > was quite difficult for them to clean up the lock-context issues that
> > > everyone else was creating.  Making lockdep check for PREEMPT_RT issues
> > > in !PREEMPT_RT kernels was therefore very helpful, at least to the
> > > PREEMPT_RT guys.
> > > 
> > > In contrast (and unlike 20 years ago), almost everyone runs SMP, so there
> > 
> > (It also means the people who cares UP is almost none ;-))
> 
> I don't know about that, given that the sets of people who run SMP and
> who care about UP are not necessarily disjoint.  But those who care *only*
> about UP definitely are no longer the vast majority.  ;-)
> 

You're right, I should have said "UP-only". And I *think* the reality is
that most of the sub-systems share the code path between UP and SMP, and
it works fine for them, because UP tests help them find SMP deadlock as
well. That's probably why lockdep has been doing this "not a good thing"
for a while.

> > > is no harm in !SMP lockdep ignoring things that would be deadlocks in
> > > SMP kernels.  The ample SMP lockdep testing will catch those issues,
> > > so there is no need for extra help from UP lockdep testing.
> > 
> > Fair point. If anyone cares UP enough to submit a patch in lockdep, I'm
> > happy to take a look.
> 
> Fair enough.
> 
> In other news, the SMP-check hack to rcutorture does suppress this lockdep
> issue, at least in my testing.  But I applied that change to my -rcu tree,
> which reverted me back to v1 of your patch and re-introduced the earlier
> lockdep issue.
> 
> So I am restarting the tests.
> 

Thank you!

Regards,
Boqun

> 							Thanx, Paul
> 
> > Regards,
> > Boqun
> > 
> > > 							Thanx, Paul
> > > 
> > > > Regards,
> > > > Boqun
> > > > 
> > > > > And of course, CONFIG_SMP=n kernels still need deadlock detection for
> > > > > mutexes and the like.
> > > > > 
> > > > > 							Thanx, Paul