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

[Boqun Feng <boqun@kernel.org>]

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

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

Regards,
Boqun

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