On 10.03.2026 10:07, Roger Pau Monné wrote:
> You possibly want to adjust the subject, instead of shrink I would use
> "dynamically allocate" or similar.
I've changed it, albeit the goal really is the shrinking.
> On Mon, Mar 09, 2026 at 04:35:34PM +0100, Jan Beulich wrote:
>> --- a/xen/common/core_parking.c
>> +++ b/xen/common/core_parking.c
>> @@ -20,6 +20,7 @@
>> #include <xen/cpumask.h>
>> #include <xen/init.h>
>> #include <xen/param.h>
>> +#include <xen/xvmalloc.h>
>>
>> #include <asm/smp.h>
>>
>> @@ -27,8 +28,8 @@
>> #define CORE_PARKING_DECREMENT 2
>>
>> static DEFINE_SPINLOCK(accounting_lock);
>> -static uint32_t cur_idle_nums;
>> -static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ... NR_CPUS-1] = -1};
>> +static unsigned int cur_idle_nums;
>> +static unsigned int *__ro_after_init core_parking_cpunum;
>
> Don't you need some kind of check in core_parking_remove() to prevent a
> NULL pointer dereference if core_parking_cpunum hasn't been allocated?
>
> Callers of XEN_SYSCTL_cpu_hotplug can set fn = smt_up_down_helper, and
> that would call core_parking_remove(). core_parking_helper() already
> contains a check that prevents accessing core_parking_cpunum if no
> policy has been registered.
Because of this check, cur_idle_nums can never become non-zero when the
array couldn't be allocated. Hence core_parking_remove() will be a
somewhat expensive no-op in that case, with no deref of core_parking_cpunum.
Jan
