On 2022-01-07 14:51:14 [-0300], Marcelo Tosatti wrote: > > wakeup_vcpus_on_cpu_lock is taken from hard interrupt context > (pi_wakeup_handler), therefore it cannot sleep. > > Switch it to a raw spinlock. > > Fixes: > > [41297.066254] BUG: scheduling while atomic: CPU 0/KVM/635218/0x00010001 > [41297.066323] Preemption disabled at: > [41297.066324] [<ffffffff902ee47f>] irq_enter_rcu+0xf/0x60 > [41297.066339] Call Trace: > [41297.066342] <IRQ> > [41297.066346] dump_stack_lvl+0x34/0x44 > [41297.066353] ? irq_enter_rcu+0xf/0x60 > [41297.066356] __schedule_bug.cold+0x7d/0x8b > [41297.066361] __schedule+0x439/0x5b0 > [41297.066365] ? task_blocks_on_rt_mutex.constprop.0.isra.0+0x1b0/0x440 > [41297.066369] schedule_rtlock+0x1e/0x40 > [41297.066371] rtlock_slowlock_locked+0xf1/0x260 > [41297.066374] rt_spin_lock+0x3b/0x60 > [41297.066378] pi_wakeup_handler+0x31/0x90 [kvm_intel] > [41297.066388] sysvec_kvm_posted_intr_wakeup_ipi+0x9d/0xd0 > [41297.066392] </IRQ> > [41297.066392] asm_sysvec_kvm_posted_intr_wakeup_ipi+0x12/0x20 > ... > > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx> so I have here v5.16 and no wakeup_vcpus_on_cpu_lock. It was also not removed so this patch is not intended for a previous kernel. Also checked next-20220111 and no wakeup_vcpus_on_cpu_lock. Sebastian