On Mon, Jun 30, 2025 at 01:42:31PM +0200, Jan Beulich wrote: > Before CPU identification has run (and it may not have run at all e.g. > when AP bringup failed altogether), cpu_data[].phys_proc_id (which is > what cpu_to_socket() resolves to) can't really be used. The use of > cpu_to_socket()'s result as an array index cpu_smpboot_free() therefore > needs guarding, as the function will also be invoked upon AP bringup > failure, in which case CPU identification may not have run. > > Without "x86/CPU: re-work populating of cpu_data[]" [1] the issue is > less pronounced: The field starts out as zero, then has the BSP value > (likely again zero) copied into it, and it is properly invalidated only > in cpu_smpboot_free(). Still it is clearly wrong to use the BSP's socket > number here. > > Making the guard work with and without the above patch applied turns out > interesting: Prior to that patch, the sole invalidation done is that in > cpu_smpboot_free(). Upon a later bringup attempt, the fields invalidated > are overwritten by the BSP values again, though. Hence compare APIC IDs, > as they cannot validly be the same once CPU identification has run. > > [1] https://lists.xen.org/archives/html/xen-devel/2024-02/msg00727.html > > Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Roger Pau Monné <roger....@citrix.com> Thanks, Roger.
