Panic observed with latest firmware, and upstream kernel: NIP init_imc_pmu+0x8c/0xcf0 LR init_imc_pmu+0x2f8/0xcf0 Call Trace: init_imc_pmu+0x2c8/0xcf0 (unreliable) opal_imc_counters_probe+0x300/0x400 platform_drv_probe+0x64/0x110 driver_probe_device+0x3d8/0x580 __driver_attach+0x14c/0x1a0 bus_for_each_dev+0x8c/0xf0 driver_attach+0x34/0x50 bus_add_driver+0x298/0x350 driver_register+0x9c/0x180 __platform_driver_register+0x5c/0x70 opal_imc_driver_init+0x2c/0x40 do_one_initcall+0x64/0x1d0 kernel_init_freeable+0x280/0x374 kernel_init+0x24/0x160 ret_from_kernel_thread+0x5c/0x74 While registering nest imc at init, cpu-hotplug callback nest_pmu_cpumask_init() makes an OPAL call to stop the engine. And if the OPAL call fails, imc_common_cpuhp_mem_free() is invoked to cleanup memory and cpuhotplug setup. But when cleaning up the attribute group, we are dereferencing the attribute element array without checking whether the backing element is not NULL. This causes the kernel panic. Add a check for the backing element prior to dereferencing the attribute element, to handle the failing case gracefully. Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> [mpe: Trim change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> |
||
---|---|---|
.. | ||
req-gen | ||
8xx-pmu.c | ||
Makefile | ||
bhrb.S | ||
callchain.c | ||
core-book3s.c | ||
core-fsl-emb.c | ||
e500-pmu.c | ||
e6500-pmu.c | ||
hv-24x7-catalog.h | ||
hv-24x7-domains.h | ||
hv-24x7.c | ||
hv-24x7.h | ||
hv-common.c | ||
hv-common.h | ||
hv-gpci-requests.h | ||
hv-gpci.c | ||
hv-gpci.h | ||
imc-pmu.c | ||
isa207-common.c | ||
isa207-common.h | ||
mpc7450-pmu.c | ||
perf_regs.c | ||
power4-pmu.c | ||
power5+-pmu.c | ||
power5-pmu.c | ||
power6-pmu.c | ||
power7-events-list.h | ||
power7-pmu.c | ||
power8-events-list.h | ||
power8-pmu.c | ||
power9-events-list.h | ||
power9-pmu.c | ||
ppc970-pmu.c |