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

[Will Deacon]

On Thu, Sep 10, 2026 at 10:47:58AM +0800, Jinjie Ruan wrote:
> 在 2026/9/9 20:36, Will Deacon 写道:
> > I was about to say "don't do this" but then I realised two things:
> > 
> > 1. update_siblings_masks() can trigger lockdep splats outside of
> >    pr_debug() if RCU isn't up and running, e.g.:
> > 
> >     [    0.524042]  show_stack+0x18/0x24 (C)
> >     [    0.524519]  __dump_stack+0x28/0x38
> >     [    0.524546]  dump_stack_lvl+0x64/0x84
> >     [    0.524562]  dump_stack+0x18/0x24
> >     [    0.524576]  lockdep_rcu_suspicious+0x134/0x1cc
> >     [    0.524591]  __lock_acquire+0xee8/0x2cb0
> >     [    0.524606]  lock_acquire+0x11c/0x2fc
> >     [    0.524621]  _raw_spin_lock_irqsave+0x64/0x84
> >     [    0.524641]  of_find_property+0x2c/0x8c
> >     [    0.524659]  detect_cache_attributes+0x1c0/0x6d0
> >     [    0.524676]  update_siblings_masks+0x38/0x288
> >     [    0.524692]  store_cpu_topology+0x4c/0x58
> >     [    0.524706]  secondary_start_kernel+0xdc/0x1c8
> >     [    0.524722]  __secondary_switched+0x120/0x124
> > 
> > 2. This code is running _after_ cpuhp_ap_sync_alive().
> > 
> > So for the next version, I'll reintroduce the call to
> > rcutree_report_cpu_starting(), but move it immediately after the call to
> > cpuhp_ap_sync_alive(). I think that will solve these issues, without
> 
> pr_crit() and pr_warn() (such as vec_verify_vq_map()) in
> check_local_cpu_capabilities() can also trigger lockdep splats as below.
> 
> But I think this is not common on the failure path, so it seems to have
> little impact..

I agree that we shouldn't bend the code out-of-shape to squash a debug
warning on an error path (ideally, printk would handle this internally),
especially as the original message does seem to get printed in the end.

> [    0.158619] smp: Bringing up secondary CPUs ...
> [    0.173958] CPU1: missing HWCAP.
> [    0.174071]
> [    0.174088] =============================
> [    0.174099] WARNING: suspicious RCU usage
> [    0.174197] 7.3.0-rc2-00020-gef0bd63bdd97-dirty #504 Tainted: G        W
> [    0.174217] -----------------------------
> [    0.174226] kernel/locking/lockdep.c:3845 RCU-list traversed in
> non-reader section!!

However, if this is caused by vec_verify_vq_map(), then how are you getting
that to run on the early boot path? check_local_cpu_capabilities() only
calls verify_local_cpu_capabilities() if system_capabilities_finalized().

Or is the backtrace for something else?

Will