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

[Jinjie Ruan]

在 2026/9/11 20:52, 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

Sorry, based on the fact that pr_crit() or pr_warn() is printed before
rcutree_report_cpu_starting() is called, I modified the code to add
print tests to simulate this situation.

> calls verify_local_cpu_capabilities() if system_capabilities_finalized().
> 
> Or is the backtrace for something else?
> 
> Will