Re: [PATCH] x86/virt: Fix RCU lockdep splat in emergency virt callback path

[Sean Christopherson]

On Sun, May 03, 2026, Mikhail Gavrilov wrote:
> x86_virt_invoke_kvm_emergency_callback() reaches rcu_dereference()
> through machine_crash_shutdown() with IRQs disabled but with RCU not
> necessarily watching, which triggers a suspicious RCU usage splat on
> debug kernels (CONFIG_PROVE_RCU=y) during panic/kdump:
> 
> WARNING: suspicious RCU usage
> arch/x86/virt/hw.c:52 suspicious rcu_dereference_check() usage!
> 
> other info that might help us debug this:
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by tee/11119:
>  #0: ffff8881fa32c440 (sb_writers#3){.+.+}-{0:0}, at: ksys_write
> 
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0x84/0xd0
>  lockdep_rcu_suspicious.cold+0x37/0x8f
>  x86_virt_invoke_kvm_emergency_callback+0x5f/0x70
>  x86_svm_emergency_disable_virtualization_cpu+0x2a/0x30
>  x86_virt_emergency_disable_virtualization_cpu+0x6b/0x90
>  native_machine_crash_shutdown+0x72/0x170
>  __crash_kexec+0x137/0x280
>  panic+0xce/0xd0
>  sysrq_handle_crash+0x1f/0x20
>  __handle_sysrq.cold+0x192/0x335
>  write_sysrq_trigger+0x8c/0xc0
>  proc_reg_write+0x1c3/0x3c0
>  vfs_write+0x1d0/0xf80
>  ksys_write+0x116/0x250
>  do_syscall_64+0x11c/0x1480
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
>  </TASK>
> 
> The RCU usage is correct: writers
> (x86_virt_{register,unregister}_emergency_callback()) serialize via
> rcu_assign_pointer() + synchronize_rcu(), while the reader on the
> emergency path runs with IRQs disabled (the only caller is
> x86_virt_emergency_disable_virtualization_cpu(), which has
> lockdep_assert_irqs_disabled()), which is a valid classic-RCU read-side
> critical section.
> 
> Use rcu_dereference_check() with irqs_disabled() to silence the splat
> without weakening the protection.
> 
> Reproducible on a debug kernel (CONFIG_PROVE_LOCKING=y, CONFIG_PROVE_RCU=y)
> with kvm_amd or kvm_intel loaded by triggering kdump:
> 
>   echo c > /proc/sysrq-trigger
> 
> Fixes: 428afac5a8ea ("KVM: x86: Move bulk of emergency virtualizaton logic to virt subsystem")
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@xxxxxxxxx>
> ---
>  arch/x86/virt/hw.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/virt/hw.c b/arch/x86/virt/hw.c
> index f647557d38ac..57eebc99299d 100644
> --- a/arch/x86/virt/hw.c
> +++ b/arch/x86/virt/hw.c
> @@ -49,7 +49,13 @@ static void x86_virt_invoke_kvm_emergency_callback(void)
>  {
>  	cpu_emergency_virt_cb *kvm_callback;
>  
> -	kvm_callback = rcu_dereference(kvm_emergency_callback);
> +	/*
> +	 * Callers invoke this with IRQs disabled (see
> +	 * x86_virt_emergency_disable_virtualization_cpu()), which is a valid
> +	 * RCU read-side critical section. Tell lockdep so it doesn't complain
> +	 * during panic/reboot paths.
> +	 */
> +	kvm_callback = rcu_dereference_check(kvm_emergency_callback, irqs_disabled());

This feels wrong.  If RCU truly isn't watching this CPU, then isn't RCU allowed
to ignore this CPU when synchronizing?

>  	if (kvm_callback)
>  		kvm_callback();
>  }
> -- 
> 2.54.0
>