Messages in this thread | | | Date | Tue, 24 Oct 2023 18:34:50 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 2/2] perf/x86/amd: Don't allow pre-emption in amd_pmu_lbr_reset() |
| |
On Tue, Oct 24, 2023 at 06:30:38PM +0200, Peter Zijlstra wrote: > On Tue, Oct 24, 2023 at 11:04:06AM -0500, Mario Limonciello wrote: > > > > IIRC this is the hotplug thread running a teardown function on that CPU > > > itself. It being a strict per-cpu thread should not trip > > > smp_processor_id() wanrs. > > > > > > > BUG: using smp_processor_id() in preemptible [00000000] code: rtcwake/2960 > > caller is amd_pmu_lbr_reset+0x19/0xc0 > > CPU: 104 PID: 2960 Comm: rtcwake Not tainted 6.6.0-rc6-00002-g3e2c7f3ac51f > > Very much not the cpuhp/%u thread :/, let me try and figure out how that > happens.
Uhh, my bad, these are the PREPARE/DEAD handlers, they run before online and after dying. The CPU is completely dead. Running lbr_reset() here makes no sense.
Did that want to be in amd_pmu_cpu_dying() ?
> > > #1025 > > Call Trace: > > <TASK> > > dump_stack_lvl+0x44/0x60 > > check_preemption_disabled+0xce/0xf0 > > ? __pfx_x86_pmu_dead_cpu+0x10/0x10 > > amd_pmu_lbr_reset+0x19/0xc0 > > ? __pfx_x86_pmu_dead_cpu+0x10/0x10 > > amd_pmu_cpu_reset.constprop.0+0x51/0x60 > > amd_pmu_cpu_dead+0x3e/0x90 > > x86_pmu_dead_cpu+0x13/0x20 > > cpuhp_invoke_callback+0x169/0x4b0 > > ? __pfx_virtnet_cpu_dead+0x10/0x10 > > __cpuhp_invoke_callback_range+0x76/0xe0 > > _cpu_down+0x112/0x270 > > freeze_secondary_cpus+0x8e/0x280
| |