All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	 Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	 "H . Peter Anvin" <hpa@zytor.com>,
	Dan Williams <djbw@kernel.org>, Chao Gao <chao.gao@intel.com>,
	x86@kernel.org,  kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/virt: Fix RCU lockdep splat in emergency virt callback path
Date: Mon, 4 May 2026 16:03:25 -0700	[thread overview]
Message-ID: <afklvRDc4wwzjkhJ@google.com> (raw)
In-Reply-To: <CABXGCsO5RCdgE0rhY_NXOmvKCDX0q=sifNryMK3qYwUuDze5AQ@mail.gmail.com>

On Tue, May 05, 2026, Mikhail Gavrilov wrote:
> On Mon, May 4, 2026 at 11:50 PM Mikhail Gavrilov
> <mikhail.v.gavrilov@gmail.com> 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).

  reply	other threads:[~2026-05-04 23:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-03 17:45 [PATCH] x86/virt: Fix RCU lockdep splat in emergency virt callback path Mikhail Gavrilov
2026-05-04 17:48 ` Sean Christopherson
2026-05-04 18:50   ` Mikhail Gavrilov
2026-05-04 21:40     ` Mikhail Gavrilov
2026-05-04 23:03       ` Sean Christopherson [this message]
2026-05-04 23:54 ` [PATCH v2] x86/virt: Silence " Mikhail Gavrilov
2026-05-07 21:59   ` Sean Christopherson
2026-05-08 19:21     ` Mikhail Gavrilov
2026-05-19  0:40   ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afklvRDc4wwzjkhJ@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=djbw@kernel.org \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikhail.v.gavrilov@gmail.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.