From: Sean Christopherson <seanjc@google.com>
To: Ben Gardon <bgardon@google.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
David Matlack <dmatlack@google.com>,
Anish Ghulati <aghulati@google.com>,
Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH v2] KVM: x86: Use SRCU to protect zap in __kvm_set_or_clear_apicv_inhibit()
Date: Wed, 2 Nov 2022 22:27:26 +0000 [thread overview]
Message-ID: <Y2Luzh+6aErzgeU4@google.com> (raw)
In-Reply-To: <20221102205359.1260980-1-bgardon@google.com>
On Wed, Nov 02, 2022, Ben Gardon wrote:
> kvm_zap_gfn_range() must be called in an SRCU read-critical section, but
> there is no SRCU annotation in __kvm_set_or_clear_apicv_inhibit(). This
> can lead to the following warning via
> kvm_arch_vcpu_ioctl_set_guest_debug() if a Shadow MMU is in use (TDP
> MMU disabled or nesting):
>
> [ 1416.659809] =============================
> [ 1416.659810] WARNING: suspicious RCU usage
> [ 1416.659839] 6.1.0-dbg-DEV #1 Tainted: G S I
> [ 1416.659853] -----------------------------
> [ 1416.659854] include/linux/kvm_host.h:954 suspicious rcu_dereference_check() usage!
> [ 1416.659856]
> ...
> [ 1416.659904] dump_stack_lvl+0x84/0xaa
> [ 1416.659910] dump_stack+0x10/0x15
> [ 1416.659913] lockdep_rcu_suspicious+0x11e/0x130
> [ 1416.659919] kvm_zap_gfn_range+0x226/0x5e0
> [ 1416.659926] ? kvm_make_all_cpus_request_except+0x18b/0x1e0
> [ 1416.659935] __kvm_set_or_clear_apicv_inhibit+0xcc/0x100
> [ 1416.659940] kvm_arch_vcpu_ioctl_set_guest_debug+0x350/0x390
> [ 1416.659946] kvm_vcpu_ioctl+0x2fc/0x620
> [ 1416.659955] __se_sys_ioctl+0x77/0xc0
> [ 1416.659962] __x64_sys_ioctl+0x1d/0x20
> [ 1416.659965] do_syscall_64+0x3d/0x80
> [ 1416.659969] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> Always take the KVM SRCU read lock in __kvm_set_or_clear_apicv_inhibit()
> to protect the GFN to memslot translation. The SRCU read lock is not
> technically required when no Shadow MMUs are in use, since the TDP MMU
> walks the paging structures from the roots and does not need to look up
> GFN translations in the memslots, but make the SRCU locking
> unconditional for simplicty.
>
> In most cases, the SRCU locking is taken care of in the vCPU run loop,
> but when called through the KVM_SET_GUEST_DEBUG IOCTL, the SRCU read
> lock is missing.
Nit, it not just KVM_SET_GUEST_DEBUG. If it were just KVM_SET_GUEST_DEBUG, I
might have advocated putting the fix KVM_SET_GUEST_DEBUG.
> Tested: ran tools/testing/selftests/kvm/x86_64/debug_regs on a DBG
> build. This patch causes the suspicious RCU warning to disappear.
> Note that the warning is hit in __kvm_zap_rmaps(), so
> kvm_memslots_have_rmaps() must return true in order for this to
> repro (i.e. the TDP MMU must be off or nesting in use.)
>
> Reported-by: Greg Thelen <gthelen@google.com>
> Fixes: 36222b117e36 ("KVM: x86: don't disable APICv memslot when inhibited")
> Signed-off-by: Ben Gardon <bgardon@google.com>
> ---
Reviewed-by: Sean Christopherson <seanjc@google.com>
next prev parent reply other threads:[~2022-11-02 22:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 20:53 [PATCH v2] KVM: x86: Use SRCU to protect zap in __kvm_set_or_clear_apicv_inhibit() Ben Gardon
2022-11-02 22:27 ` Sean Christopherson [this message]
2022-11-03 13:35 ` Paolo Bonzini
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=Y2Luzh+6aErzgeU4@google.com \
--to=seanjc@google.com \
--cc=aghulati@google.com \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=gthelen@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/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.