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

[Anju T Sudhakar]

Hi,


On Saturday 12 May 2018 06:05 AM, Balbir Singh wrote:
> 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.
>

Thanks for the review.
OK. I will update the commit message here.



Regards,
Anju