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

[Mikhail Gavrilov]

On Mon, May 4, 2026 at 10:48 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> This feels wrong.  If RCU truly isn't watching this CPU, then isn't RCU allowed
> to ignore this CPU when synchronizing?
>

You're correct that irqs_disabled() doesn't imply RCU is watching, and
in the general case that would be a real concern. However, on the
emergency virt callback path the practical situation is narrower:

  1. The reader (x86_virt_invoke_kvm_emergency_callback) only runs from
     panic/kexec/reboot via x86_virt_emergency_disable_virtualization_cpu()
     and machine_crash_shutdown().

  2. The writer (x86_virt_unregister_emergency_callback) calls
     synchronize_rcu(), which would observe an RCU read-side critical
     section started by rcu_read_lock(). But on the panic path we don't
     have rcu_read_lock() — we just have IRQs disabled. So even with my
     patch, a concurrent unregister could in principle free the callback
     out from under us.

  3. In practice, the writer can only run from KVM module unload. By
     the time we're in panic context, all CPUs except the crashing one
     have been NMI'd into x86_svm_emergency_disable_virtualization_cpu
     too — a kvm_amd unload happening concurrently with panic seems
     extraordinarily unlikely, and the system is going down regardless.

So the splat is technically a real issue, but the underlying race is
already so vanishingly small that I'm not sure what the right fix
shape is. Some options:

  a) Treat this as "panic context can't be RCU-correct anyway" and
     use rcu_dereference_raw() with a comment.

  b) Convert kvm_emergency_callback away from RCU (it's only set/cleared
     once per KVM module lifetime; a regular pointer with smp_store_release/
     smp_load_acquire would suffice).

  c) Keep my patch but document that it's a minor lockdep silencer for
     a path where the use-after-free window is closed by other means
     (panic-time module unload being unrealistic).

What direction would you prefer? I'm happy to spin v2 as needed.

-- 
Best Regards,
Mike Gavrilov.