public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	rkrcmar@redhat.com
Subject: Re: [PATCH v1 01/22] KVM: x86: race between KVM_SET_GSI_ROUTING and KVM_CREATE_IRQCHIP
Date: Wed, 15 Mar 2017 17:28:19 +0800	[thread overview]
Message-ID: <20170315092819.GF5971@pxdev.xzpeter.org> (raw)
In-Reply-To: <4295fa2c-217d-dce0-e749-175abf41c1a4@redhat.com>

On Wed, Mar 15, 2017 at 10:19:53AM +0100, David Hildenbrand wrote:
> Am 15.03.2017 um 07:24 schrieb Peter Xu:
> > On Tue, Mar 14, 2017 at 02:34:29PM +0100, David Hildenbrand wrote:
> >> Avoid races between KVM_SET_GSI_ROUTING and KVM_CREATE_IRQCHIP by taking
> >> the kvm->lock when setting up routes.
> >>
> >> If KVM_CREATE_IRQCHIP fails, KVM_SET_GSI_ROUTING could have already set
> >> up routes pointing at pic/ioapic, being silently removed already.
> >>
> >> Signed-off-by: David Hildenbrand <david@redhat.com>
> >> ---
> >>  virt/kvm/kvm_main.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> >> index a17d787..ad0f8b2 100644
> >> --- a/virt/kvm/kvm_main.c
> >> +++ b/virt/kvm/kvm_main.c
> >> @@ -3079,8 +3079,11 @@ static long kvm_vm_ioctl(struct file *filp,
> >>  					   routing.nr * sizeof(*entries)))
> >>  				goto out_free_irq_routing;
> >>  		}
> >> +		/* avoid races with KVM_CREATE_IRQCHIP on x86 */
> >> +		mutex_lock(&kvm->lock);
> >>  		r = kvm_set_irq_routing(kvm, entries, routing.nr,
> >>  					routing.flags);
> >> +		mutex_unlock(&kvm->lock);
> >>  out_free_irq_routing:
> >>  		vfree(entries);
> >>  		break;
> >> -- 
> >> 2.9.3
> >>
> > 
> > Out of my curiousity: do we have a use case that these two operations
> > might collapse (KVM_CREATE_IRQCHIP and KVM_SET_GSI_ROUTING)? Or is
> > this patch only for the sake of security?
> 
> Just for the sake of security. I think, in general such calls are not
> supposed to be done in parallel. But of course, user space can.

I see.

> 
> > 
> > Another thing to mention is that, I guess adding this lock will
> > benefit KVM_CAP_SPLIT_IRQCHIP as well, maybe nice to mention it too in
> > the commit message. No worth a repost for this single reason though.
> > 
> 
> I added
> 
> "Also, as a side effect, this patch makes sure that KVM_SET_GSI_ROUTING
> and KVM_CAP_SPLIT_IRQCHIP cannot run in parallel."

Yeah it looks better. Thanks!

-- peterx

  reply	other threads:[~2017-03-15  9:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-14 13:34 [PATCH v1 00/22] pic/ioapic/irqchip cleanups + minor fixes David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 01/22] KVM: x86: race between KVM_SET_GSI_ROUTING and KVM_CREATE_IRQCHIP David Hildenbrand
2017-03-15  6:24   ` Peter Xu
2017-03-15  9:19     ` David Hildenbrand
2017-03-15  9:28       ` Peter Xu [this message]
2017-03-14 13:34 ` [PATCH v1 02/22] KVM: x86: check against irqchip_mode in kvm_set_routing_entry() David Hildenbrand
2017-03-15  6:33   ` Peter Xu
2017-03-15  9:35     ` David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 03/22] KVM: x86: check against irqchip_mode in pic_in_kernel() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 04/22] KVM: x86: check against irqchip_mode in ioapic_in_kernel() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 05/22] KVM: x86: get rid of pic_irqchip() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 06/22] KVM: x86: get rid of ioapic_irqchip() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 07/22] KVM: x86: use ioapic_in_kernel() to check for ioapic existence David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 08/22] KVM: x86: remove duplicate checks for ioapic David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 09/22] KVM: x86: convert kvm_(set|get)_ioapic() into void David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 10/22] KVM: x86: don't take kvm->irq_lock when creating IRQCHIP David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 11/22] KVM: x86: push usage of slots_lock down David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 12/22] KVM: x86: KVM_IRQCHIP_PIC_MASTER only has 8 pins David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 13/22] KVM: x86: remove all-vcpu request from kvm_ioapic_init() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 14/22] KVM: x86: directly call kvm_make_scan_ioapic_request() in ioapic.c David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 15/22] KVM: x86: rename kvm_vcpu_request_scan_ioapic() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 16/22] KVM: x86: drop goto label in kvm_set_routing_entry() David Hildenbrand
2017-03-15  8:23   ` Peter Xu
2017-03-15  9:11     ` David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 17/22] KVM: x86: simplify pic_unlock() David Hildenbrand
2017-03-15  8:27   ` Peter Xu
2017-03-15  9:07     ` David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 18/22] KVM: x86: make kvm_pic_reset() static David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 19/22] KVM: x86: drop picdev_in_range() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 20/22] KVM: x86: set data directly in picdev_read() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 21/22] KVM: x86: simplify pic_ioport_read() David Hildenbrand
2017-03-14 13:34 ` [PATCH v1 22/22] KVM: x86: use irqchip_kernel() to check for pic+ioapic David Hildenbrand

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=20170315092819.GF5971@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox