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

[Sean Christopherson]

On Tue, May 05, 2026, Mikhail Gavrilov wrote:
> On Mon, May 4, 2026 at 11:50 PM Mikhail Gavrilov
> <mikhail.v.gavrilov@xxxxxxxxx> wrote:
> >
> > What direction would you prefer? I'm happy to spin v2 as needed.
> >
> 
> After looking at how other places in the kernel handle this — kernel/notifier.c,
> kernel/cgroup/cgroup.c, kernel/fork.c, kernel/sched/fair.c all use
> rcu_dereference_raw() when the caller has context-specific knowledge that
> makes lockdep checks inappropriate.
> 
> I'll send v2 using rcu_dereference_raw() with a comment explaining the
> panic-context reasoning. The diff would look like:
> 
>   /*
>    * The crashing CPU may be outside RCU's watching set in panic context.
>    * Use rcu_dereference_raw() to avoid lockdep complaints — the writers
>    * (KVM module load/unload) cannot run during emergency virt callback
>    * invocation, so the pointer is effectively stable here.

AFAIK, nothing actually prevents module unload when the kernel is panicking and/or
rebooting.  E.g. see commit 2baa33a8ddd6 ("KVM: x86: Leave user-return notifier
registered on reboot/shutdown").

>    */
>   kvm_callback = rcu_dereference_raw(kvm_emergency_callback);
> 
> Let me know if you'd prefer a different approach (option (b) from my
> previous mail — converting away from RCU entirely — is a bigger change
> but I can do that instead).

For "normal" usage, if there really is even such a thing for this case,
smp_store_release() / smp_load_acquire() won't suffice, because the kernel needs
to ensure the module text isn't freed while the callback is in-flight.

But as you noted before, if the kernel is panicking, (a) the window for anything
to go wrong is comically small, and (b) at some point the kernel _can't_ guarantee
that everything will be "fine".  So I'd probably be ok with just sweeping this
under the rug?  Assuming we can't come up with an easy-ish solution that doesn't
require taking locks (which to me, would have a higher probability of causing
problems).