[PATCH 09/19] arm64: smp: Defer RCU registration during secondary CPU bringup

[Will Deacon]

Hi Jinjie,

On Tue, Sep 08, 2026 at 04:55:36PM +0800, Jinjie Ruan wrote:
> 在 2026/9/8 0:40, Will Deacon 写道:
> > Calling rcutree_report_cpu_starting() early during boot can lead to
> > livelocks with the generic CPU hotplug mechanism if the boot CPU blocks
> > on an RCU grace period while the CPU being onlined is spinning in
> > cpuhp_ap_sync_alive().
> > 
> > In preparation for enabling the generic CPU hotplug code on arm64, split
> > up the trace_hardirqs_off() call during secondary CPU bringup so that we
> > update lockdep early but defer the tracing updates until after
> > notify_cpu_starting() has registered the new CPU with RCU, allowing us
> > to drop the explicit call to rcutree_report_cpu_starting() entirely.
> > 
> > Signed-off-by: Will Deacon <will at kernel.org>
> > ---
> >  arch/arm64/kernel/smp.c | 5 ++---
> >  include/linux/rcutree.h | 2 +-
> >  2 files changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index f4cabf9e19e6..ff68640d0c0b 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -217,8 +217,7 @@ asmlinkage notrace void secondary_start_kernel(void)
> >  	if (system_uses_irq_prio_masking())
> >  		init_gic_priority_masking();
> >  
> > -	rcutree_report_cpu_starting(cpu);
> > -	trace_hardirqs_off();
> 
> I think we need to handle the printk problem before this patch as we
> discussed earlier.
> 
> Otherwise defer the rcutree_report_cpu_starting() will trigger a
> false-positive lockdep"suspicious RCU usage" splat during early lock
> acquisitions as commit ce3d31ad3cac ("arm64/smp: Move
> rcu_cpu_starting() earlier") pointed out.

Sorry, I meant to mention this in the cover letter but forgot about it.
I'm not sure that ce3d31ad3cac ("arm64/smp: Move rcu_cpu_starting()
earlier") is still relevant with the latest printk/console/lockdep code.
I tried quite hard to trigger lockdep splats manually, but the only way
I could do it was by using the "%pS" specifier to print the name of a
symbol in a module, which would cause an RCU walk of the module symbols
in the kallsyms code! Manually calling WARN() or even rcu_read_lock() /
spin_lock() did _not_ trigger a splat.

Since that's not something I think we should be doing this early, I
decided to leave the code as-is unless I have a way to trigger a lockdep
splat with the relatively simple prints we have on the early error paths.

Will