All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Michal Luczaj <mhal@rbox.co>,
	dwmw2@infradead.org, kvm@vger.kernel.org, paul@xen.org
Subject: Re: [PATCH 1/2] KVM: x86: Fix deadlock in kvm_vm_ioctl_set_msr_filter()
Date: Thu, 5 Jan 2023 23:07:33 +0000	[thread overview]
Message-ID: <Y7dYNR/39fTOuaPR@google.com> (raw)
In-Reply-To: <3a4ab7b0-67f3-f686-0471-1ae919d151b5@redhat.com>

On Fri, Jan 06, 2023, Paolo Bonzini wrote:
> On 1/5/23 23:23, Sean Christopherson wrote:
> > Ha!  Case in point.  The aforementioned Xen code blatantly violates KVM's locking
> > rules:
> > 
> >    - kvm->lock is taken outside vcpu->mutex
> 
> Ouch yeah, that's not salvageable.  Anything that takes kvm->lock inside
> kvm->srcu transitively has to be taking kvm->lock inside vcpu->mutex as
> well.
> 
> In abstract I don't think that "vcpu->mutex inside kvm->lock" would be a
> particularly problematic rule; kvm->lock critical sections are much shorter
> than vcpu->mutex which covers all of KVM_RUN for example, and that hints at
> making vcpu->mutex the *outer* mutex.  However, I completely forgot the
> sev_lock_vcpus_for_migration case, which is the exception that... well,
> disproves the rule.

Ya, and there are plenty more instances outside of x86.

ARM's vGIC stuff also does similar things, see lock_all_vcpus().

PPC's kvmppc_xive_release() and kvmppc_xics_release().

s390's kvm_s390_cpus_from_pv().

  reply	other threads:[~2023-01-05 23:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 20:30 [RFC PATCH 0/2] Use-after-free in kvm_xen_eventfd_update() Michal Luczaj
2022-12-22 20:30 ` [RFC PATCH 1/2] KVM: x86/xen: Fix use-after-free " Michal Luczaj
2022-12-24  8:52   ` Paolo Bonzini
2022-12-24 11:14     ` Michal Luczaj
2022-12-27 11:11       ` Paolo Bonzini
2022-12-28  0:21         ` Michal Luczaj
2022-12-28  9:32           ` David Woodhouse
2022-12-28  9:39           ` Paolo Bonzini
2022-12-28  9:54             ` David Woodhouse
2022-12-28 11:58               ` Paolo Bonzini
2022-12-28 12:35                 ` David Woodhouse
2022-12-28 13:14                   ` Paolo Bonzini
2022-12-29  2:12                 ` Michal Luczaj
2022-12-29 21:03                   ` Paolo Bonzini
2022-12-29 21:17                     ` [PATCH 0/2] Fix deadlocks in kvm_vm_ioctl_set_msr_filter() and Michal Luczaj
2022-12-29 21:17                       ` [PATCH 1/2] KVM: x86: Fix deadlock in kvm_vm_ioctl_set_msr_filter() Michal Luczaj
2023-01-03 17:17                         ` Sean Christopherson
2023-01-03 17:28                           ` Sean Christopherson
2023-01-05 19:32                           ` Michal Luczaj
2023-01-05 22:23                             ` Sean Christopherson
2023-01-05 23:02                               ` Paolo Bonzini
2023-01-05 23:07                                 ` Sean Christopherson [this message]
2023-01-10 12:55                                 ` David Woodhouse
2023-01-10 14:10                                   ` Paolo Bonzini
2023-01-10 15:27                                     ` David Woodhouse
2023-01-10 19:17                                     ` David Woodhouse
2023-01-10 19:37                                       ` Sean Christopherson
2023-01-10 19:46                                         ` David Woodhouse
2023-01-11  8:49                                       ` David Woodhouse
2023-01-11 22:49                                         ` Paolo Bonzini
2023-01-06 10:06                               ` David Woodhouse
2023-01-07  0:06                               ` Michal Luczaj
2023-01-05 22:46                         ` Sean Christopherson
2022-12-29 21:17                       ` [PATCH 2/2] KVM: x86: Fix deadlock in kvm_vm_ioctl_set_pmu_event_filter() Michal Luczaj
2022-12-22 20:30 ` [RFC PATCH 2/2] KVM: x86/xen: Simplify eventfd IOCTLs Michal Luczaj
2022-12-24  8:54   ` 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=Y7dYNR/39fTOuaPR@google.com \
    --to=seanjc@google.com \
    --cc=dwmw2@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=mhal@rbox.co \
    --cc=paul@xen.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.