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

Will Deacon will at kernel.org
Tue Jul 7 03:27:07 PDT 2026


Jinjie,

On Tue, Jul 07, 2026 at 11:02:32AM +0800, Jinjie Ruan wrote:
> On 7/7/2026 1:39 AM, Will Deacon wrote:
> > 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.

It's great that your AI chatbot thinks this is fantastic, but what do
_you_ think? I'm much more interested in your opinion, as you have
already spent time thinking about this.

Will



More information about the linux-arm-kernel mailing list