[v2] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
patch-notifications at ellerman.id.au
Mon May 21 20:01:26 AEST 2018
On Wed, 2018-05-16 at 06:35:18 UTC, Anju T Sudhakar 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 the array index to access the memory.
> Under some circumstances firmware marks a CPU as GUARDed CPU and boot the
> system, until cleared of errors, these CPU's are unavailable for all
> subsequent boots. GUARDed CPUs are possible but not present from linux
> view, 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.
> So (cpu number / threads per core) value bounds the array index and leads
> to memory overflow.
> Call trace observed during a guard test:
> Faulting instruction address: 0xc000000000149f1c
> cpu 0x69: Vector: 380 (Data Access Out of Range) at [c000003fea303420]
> pc:c000000000149f1c: prefetch_freepointer+0x14/0x30
> lr:c00000000014e0f8: __kmalloc+0x1a8/0x1ac
> current = 0xc000003fea2c0000
> paca = 0xc00000000fddd880 softe: 3 irq_happened: 0x01
> pid = 1, comm = swapper/104
> Linux version 4.16.7-openpower1 (smc at smc-desktop) (gcc version 6.4.0
> (Buildroot 2018.02.1-00006-ga8d1126)) #2 SMP Fri May 4 16:44:54 PDT 2018
> enter ? for help
> call trace:
> 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>
> Reviewed-by: Balbir Singh <bsingharora at gmail.com>
> Tested-by: Pridhiviraj Paidipeddi <ppaidipe at linux.vnet.ibm.com>
Applied to powerpc next, thanks.
More information about the Linuxppc-dev