On Tue, Mar 10, 2026 at 10:20:53AM +0100, Jan Beulich wrote:
> 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.
Oh, I see, both loops in core_parking_remove() are bounded to
cur_idle_nums.
Reviewed-by: Roger Pau Monné <[email protected]>
Thanks, Roger.
