arc_pmu_device_probe: BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1

[abrodkin]

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.

[kokas-a]

Suggested fix located here: http://lists.infradead.org/pipermail/linux-snps-arc/2022-May/005952.html

[abrodkin]

@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.

[kokas-a]

New link to the fix: http://lists.infradead.org/pipermail/linux-snps-arc/2023-April/007106.html

[xxkent]

I've added this patch to the arc64 branch.
563ea97