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

[Jinjie Ruan <ruanjinjie@huawei.com>]

On 7/7/2026 1:39 AM, Will Deacon wrote:
> 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.

Hi Will,

I fully share your concern. Disabling lockdep globally or even across a
large function like check_local_cpu_capabilities() is risky — it would
suppress *all* lock validation in that path, not just the harmless
early-boot warnings.

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

That is an excellent point. Reworking cpu_die_early() and
cpu_panic_kernel() to uniformly use printk_deferred() based on the
specific error type or the string argument is a much cleaner approach.

This makes perfect sense because these paths are inherently fatal, and
switching to deferred printing avoids the risky lock-taking and RCU
runtime constraints during early boot entirely. It cleanly resolves the
diagnostic noise without broadly blinding lockdep or hiding potential
locking issues down the line.

I fully agree with this approach.

Best regards,
Jinjie

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