[PATCH] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()

Balbir Singh bsingharora at gmail.com
Sat May 12 10:35:13 AEST 2018


On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar
<anju at linux.vnet.ibm.com> wrote:
> Currently memory is allocated for core-imc based on cpu_present_mask, which has
> bit 'cpu' set iff cpu is populated. We use  (cpu number / threads per core)
> as as array index to access the memory.
> So in a system with guarded cores, since allocation happens based on
> cpu_present_mask, (cpu number / threads per core) bounds the index and leads
> to memory overflow.
>
> The issue is exposed in a guard test.
> The guard test will make some CPU's as un-available to the system during boot
> time as well as at runtime. So when the cpu is unavailable to the system during
> boot time, the memory allocation happens depending on the number of available
> cpus. And when we access the memory using (cpu number / threads per core) as the
> index the system crashes due to memory overflow.
>
> Allocating memory for core-imc based on cpu_possible_mask, which has
> bit 'cpu' set iff cpu is populatable, will fix this issue.
>
> Reported-by: Pridhiviraj Paidipeddi <ppaidipe at linux.vnet.ibm.com>
> Signed-off-by: Anju T Sudhakar <anju at linux.vnet.ibm.com>
> ---
>  arch/powerpc/perf/imc-pmu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

The changelog does not clearly call out the confusion between present
and possible.
Guarded CPUs are possible but not present, so it blows a hole when we assume the
max length of our allocation is driven by our max present cpus, where
as one of the cpus
might be online and be beyond the max present cpus, due to the hole..

Reviewed-by: Balbir Singh <bsingharora at gmail.com>

Balbir Singh.


More information about the Linuxppc-dev mailing list