On 2016-10-20 16:27:55 [-0400], Charles (Chas) Williams wrote: > Recent 4.8 kernels have been oopsing when running under VMWare:
can you reproduce this on bare metal? > [ 2.270203] BUG: unable to handle kernel NULL pointer dereference at > 0000000000000408 > [ 2.270325] IP: [<ffffffff81012bb9>] rapl_cpu_online+0x59/0x70 … > > gdb tells me: > > (gdb) info line *(rapl_cpu_online+0x59) > Line 595 of "arch/x86/events/intel/rapl.c" starts at address > 0xffffffff81012bb9 <rapl_cpu_online+89> > and ends at 0xffffffff81012bbe <rapl_cpu_online+94>. > > Which is: > > > target = cpumask_any_and(&rapl_cpu_mask, topology_core_cpumask(cpu)); > if (target < nr_cpu_ids) > return 0; > > cpumask_set_cpu(cpu, &rapl_cpu_mask); > pmu->cpu = cpu; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< can you check if pmu is NULL? > return 0; … > Is there a particular order guaranteed by the callbacks? Will > rapl_cpu_prepare() always happen before online/offline? Additionally, yes, see include/linux/cpuhotplug.h. On CPU-up the array ids are invoked from CPUHP_OFFLINE till CPUHP_ONLINE. > rapl_cpu_prepare() can fail to allocate pmu, error codes callbacks are handled. … > But rapl_cpu_online() would have no idea about this. What should be > done in this case? If a callback (such as CPUHP_PERF_X86_RAPL_PREP) fail then we rollback to the starting point (in case of CPU up it would be CPUHP_OFFLINE. Sebastian
