Anju T Sudhakar <a...@linux.vnet.ibm.com> writes: > On Saturday 12 May 2018 06:05 AM, Balbir Singh wrote: >> On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar >> <a...@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 <ppaid...@linux.vnet.ibm.com> >>> Signed-off-by: Anju T Sudhakar <a...@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 <bsinghar...@gmail.com> > > Thanks for the review. > OK. I will update the commit message here.
Yeah please do. "Guarded" CPUs is also not a well understand term, so please explain what that means for people who don't know. cheers
