Messages in this thread | | | Date | Fri, 25 Mar 2022 15:18:52 -0400 | Subject | Re: [PATCH v2] xen: fix is_xen_pmu() | From | Boris Ostrovsky <> |
| |
On 3/25/22 10:20 AM, Juergen Gross wrote: > is_xen_pmu() is taking the cpu number as parameter, but it is not using > it. Instead it just tests whether the Xen PMU initialization on the > current cpu did succeed. As this test is done by checking a percpu > pointer, preemption needs to be disabled in order to avoid switching > the cpu while doing the test. While resuming from suspend() this seems > not to be the case: > > [ 88.082751] ACPI: PM: Low-level resume complete > [ 88.087933] ACPI: EC: EC started > [ 88.091464] ACPI: PM: Restoring platform NVS memory > [ 88.097166] xen_acpi_processor: Uploading Xen processor PM info > [ 88.103850] Enabling non-boot CPUs ... > [ 88.108128] installing Xen timer for CPU 1 > [ 88.112763] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-sleep/7138 > [ 88.122256] caller is is_xen_pmu+0x12/0x30 > [ 88.126937] CPU: 0 PID: 7138 Comm: systemd-sleep Tainted: G W 5.16.13-2.fc32.qubes.x86_64 #1 > [ 88.137939] Hardware name: Star Labs StarBook/StarBook, BIOS 7.97 03/21/2022 > [ 88.145930] Call Trace: > [ 88.148757] <TASK> > [ 88.151193] dump_stack_lvl+0x48/0x5e > [ 88.155381] check_preemption_disabled+0xde/0xe0 > [ 88.160641] is_xen_pmu+0x12/0x30 > [ 88.164441] xen_smp_intr_init_pv+0x75/0x100 > > Fix that by replacing is_xen_pmu() by a simple boolean variable which > reflects the Xen PMU initialization state on cpu 0. > > Modify xen_pmu_init() to return early in case it is being called for a > cpu other than cpu 0 and the boolean variable not being set. > > Fixes: bf6dfb154d93 ("xen/PMU: PMU emulation code") > Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> > Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
| |