xen/arm: smpboot: Allocate the CPU sibling/core maps while preparing the CPU
authorJulien Grall <jgrall@amazon.com>
Wed, 22 Jun 2022 17:51:17 +0000 (18:51 +0100)
committerJulien Grall <jgrall@amazon.com>
Wed, 22 Jun 2022 17:52:24 +0000 (18:52 +0100)
commit65f684b728f779e170335e9e0cbbf82f7e1c7e5b
tree9caece4a49b8a2e9fa18f6c73d9c5b4aecb6d986
parent15d93068e3484cb14006e935734a1e6088f228fd
xen/arm: smpboot: Allocate the CPU sibling/core maps while preparing the CPU

Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupts disabled.

Unfortunately, the rule is not followed when allocating the CPU
sibling/core maps.

(XEN) Xen call trace:
(XEN)    [<00238a5c>] _xmalloc+0xfc/0x314 (PC)
(XEN)    [<00000000>] 00000000 (LR)
(XEN)    [<00238c8c>] _xzalloc+0x18/0x4c
(XEN)    [<00288cb4>] smpboot.c#setup_cpu_sibling_map+0x38/0x138
(XEN)    [<00289024>] start_secondary+0x1b4/0x270
(XEN)    [<40010170>] 40010170
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 2:
(XEN) Assertion '!in_irq() && (local_irq_is_enabled() || num_online_cpus() <= 1)' failed at common/xmalloc_tlsf.c:601
(XEN) ****************************************

This is happening because zalloc_cpumask_var() may allocate memory
if NR_CPUS is > 2 * sizeof(unsigned long).

Avoid the problem by allocating the CPU sibling/core maps while
preparing the CPU.

This also has the benefit to remove a panic() in the secondary CPU
code.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
xen/arch/arm/smpboot.c