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

["Paul E. McKenney" <paulmck@kernel.org>]

On Sun, Mar 22, 2026 at 01:26:02PM -0700, Boqun Feng wrote:
> 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.

There are many instances of "#ifdef CONFIG_SMP", too many to avoid
activating my laziness.

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

With these commits in addition:

79e15e57059e ("rcutorture: Test call_srcu() with pi_lock held only for SMP")
	(from my -rcu tree)
ca174c705db5 ("cgroup/cpuset: Call rebuild_sched_domains() directly in hotplug")
	(from mainline)

Tested-by: Paul E. McKenney <paulmck@kernel.org>

							Thanx, Paul

> 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