All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@ozlabs.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 0/4] KVM: PPC: Book3S: Fix potential deadlocks
Date: Tue, 28 May 2019 14:54:27 +1000	[thread overview]
Message-ID: <20190528045427.fwbhxpjzcz2imqqk@oak.ozlabs.ibm.com> (raw)
In-Reply-To: <3633e945-7126-c655-587d-e09eafb9f9f3@kaod.org>

On Fri, May 24, 2019 at 11:17:16AM +0200, Cédric Le Goater wrote:
> On 5/23/19 8:34 AM, Paul Mackerras wrote:
> > Recent reports of lockdep splats in the HV KVM code revealed that it
> > was taking the kvm->lock mutex in several contexts where a vcpu mutex
> > was already held.  Lockdep has only started warning since I added code
> > to take the vcpu mutexes in the XIVE device release functions, but
> > since Documentation/virtual/kvm/locking.txt specifies that the vcpu
> > mutexes nest inside kvm->lock, it seems that the new code is correct
> > and it is most of the old uses of kvm->lock that are wrong.
> > 
> > This series should fix the problems, by adding new mutexes that nest
> > inside the vcpu mutexes and using them instead of kvm->lock.
> 
> Hello,
> 
> I guest this warning when running a guest with this patchset :

Looks like we need the equivalent of 3309bec85e60 applied to the
p9/radix streamlined entry path.

Paul.

WARNING: multiple messages have this Message-ID (diff)
From: Paul Mackerras <paulus@ozlabs.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 0/4] KVM: PPC: Book3S: Fix potential deadlocks
Date: Tue, 28 May 2019 04:54:27 +0000	[thread overview]
Message-ID: <20190528045427.fwbhxpjzcz2imqqk@oak.ozlabs.ibm.com> (raw)
In-Reply-To: <3633e945-7126-c655-587d-e09eafb9f9f3@kaod.org>

On Fri, May 24, 2019 at 11:17:16AM +0200, Cédric Le Goater wrote:
> On 5/23/19 8:34 AM, Paul Mackerras wrote:
> > Recent reports of lockdep splats in the HV KVM code revealed that it
> > was taking the kvm->lock mutex in several contexts where a vcpu mutex
> > was already held.  Lockdep has only started warning since I added code
> > to take the vcpu mutexes in the XIVE device release functions, but
> > since Documentation/virtual/kvm/locking.txt specifies that the vcpu
> > mutexes nest inside kvm->lock, it seems that the new code is correct
> > and it is most of the old uses of kvm->lock that are wrong.
> > 
> > This series should fix the problems, by adding new mutexes that nest
> > inside the vcpu mutexes and using them instead of kvm->lock.
> 
> Hello,
> 
> I guest this warning when running a guest with this patchset :

Looks like we need the equivalent of 3309bec85e60 applied to the
p9/radix streamlined entry path.

Paul.

  reply	other threads:[~2019-05-28  4:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23  6:34 [PATCH 0/4] KVM: PPC: Book3S: Fix potential deadlocks Paul Mackerras
2019-05-23  6:34 ` Paul Mackerras
2019-05-23  6:35 ` [PATCH 1/4] KVM: PPC: Book3S HV: Avoid touching arch.mmu_ready in XIVE release functions Paul Mackerras
2019-05-23  6:35   ` Paul Mackerras
2019-05-23  6:35 ` [PATCH 2/4] KVM: PPC: Book3S HV: Use new mutex to synchronize MMU setup Paul Mackerras
2019-05-23  6:35   ` Paul Mackerras
2019-05-23  6:36 ` [PATCH 3/4] KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list Paul Mackerras
2019-05-23  6:36   ` Paul Mackerras
2019-05-23  7:11   ` Cédric Le Goater
2019-05-23  7:11     ` Cédric Le Goater
2019-05-29  1:54   ` [PATCH v2 " Paul Mackerras
2019-05-29  1:54     ` Paul Mackerras
2019-05-23  6:36 ` [PATCH 4/4] KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu Paul Mackerras
2019-05-23  6:36   ` Paul Mackerras
2019-05-23  7:11   ` Cédric Le Goater
2019-05-23  7:11     ` Cédric Le Goater
2019-05-23  7:21 ` [PATCH 0/4] KVM: PPC: Book3S: Fix potential deadlocks Alexey Kardashevskiy
2019-05-23  7:21   ` Alexey Kardashevskiy
2019-05-23  7:41   ` Cédric Le Goater
2019-05-23  7:41     ` Cédric Le Goater
2019-05-23  8:31   ` Paul Mackerras
2019-05-23  8:31     ` Paul Mackerras
2019-05-24  9:17 ` Cédric Le Goater
2019-05-24  9:17   ` Cédric Le Goater
2019-05-28  4:54   ` Paul Mackerras [this message]
2019-05-28  4:54     ` Paul Mackerras
2019-05-31  6:32 ` Paul Mackerras
2019-05-31  6:32   ` Paul Mackerras

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=20190528045427.fwbhxpjzcz2imqqk@oak.ozlabs.ibm.com \
    --to=paulus@ozlabs.org \
    --cc=clg@kaod.org \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.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.