[PATCH v3 05/12] arm64: smp: Defer RCU registration during secondary CPU bringup

[Will Deacon]

On Wed, Jun 24, 2026 at 05:25:30PM +0800, Jinjie Ruan wrote:
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index c14b179c595d..87f92cf9ffa8 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -35,6 +35,7 @@
>  #include <linux/kgdb.h>
>  #include <linux/kvm_host.h>
>  #include <linux/nmi.h>
> +#include <linux/lockdep.h>
>  
>  #include <asm/alternative.h>
>  #include <asm/atomic.h>
> @@ -215,15 +216,23 @@ 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();
> +	lockdep_hardirqs_off(CALLER_ADDR0);
>  
> +	/*
> +	 * Since RCU is still offline on this CPU, any nested native printk
> +	 * or lock acquisition would normally trigger a false-positive
> +	 * "suspicious RCU usage" lockdep splat.
> +	 */
> +	lockdep_off();

On the flip side, should we really be taking locks at this point? I'm
actually quite sympathetic to lockdep here and I worry that disabling
it briefly is going to hide real problems down the line.

ce3d31ad3cac ("arm64/smp: Move rcu_cpu_starting() earlier") was to
handle the useless print in cpuinfo_detect_icache_policy(), but I've
decided just to remove that one. So I think the remaining prints we have
to worry about in this early boot code are from error paths in the
CPU feature detection logic (check_local_cpu_capabilities()).

Given that those error paths should all be fatal, perhaps we could
rework cpu_die_early() and cpu_panic_kernel() as macros that take a
string argument and either call printk_deferred() (similarly to what you
suggested in a previous version of your series [1]) or do the
lockdep_off() there before a pr_crit().

What do you think?

Will

[1] https://lore.kernel.org/all/20260618092444.1316336-4-ruanjinjie@huawei.com/