arc_pmu_device_probe: BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
Opened this issue · 4 comments
With enabled CONFIG_DEBUG_PREEMPT the following stack-trace gets printed on SMP ARC platforms with performance counters interrupts:
ARC perf : 8 counters (48 bits), 128 conditions, [overflow IRQ support]
BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
caller is arc_pmu_device_probe+0x336/0x3c8
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.17.0 #2
Stack Trace:
arc_unwind_core+0xe8/0x118
dump_stack_lvl+0x48/0x68
check_preemption_disabled+0xb4/0xb8
arc_pmu_device_probe+0x336/0x3c8
platform_probe+0x30/0x80
really_probe.part.0+0x88/0x240
driver_probe_device+0x86/0x1ec
__driver_attach+0x8a/0x144
bus_for_each_dev+0x38/0x64
bus_add_driver+0x116/0x17c
driver_register+0x4c/0xdc
do_one_initcall+0x30/0x16c
kernel_init_freeable+0x1be/0x224
workingset: timestamp_bits=14 max_order=15 bucket_order=1
io scheduler mq-deadline registered
That happens because of use of this_cpu_ptr() in https://elixir.bootlin.com/linux/v5.17/source/arch/arc/kernel/perf_event.c#L811 without explicitly disabled preemption, see https://www.kernel.org/doc/html/latest/core-api/this_cpu_ops.html#special-operations.
We need either to re-work that code so that it uses preemption-agnostic functions or explicitly disable preemption around that code.
Suggested fix located here: http://lists.infradead.org/pipermail/linux-snps-arc/2022-May/005952.html
@kokas-a could you please rebase your proposed fix on top of the current Linus' master branch and re-send it to the mailing list. We need to make sure it gets accepted in the upstream project. And in the meantime also create a pull-request here against arc64 branch with that same fix, so we have it in our tree as well.
New link to the fix: http://lists.infradead.org/pipermail/linux-snps-arc/2023-April/007106.html