From: Paolo Bonzini <pbonzini@redhat.com>
To: Christoffer Dall <christoffer.dall@linaro.org>, kvm@vger.kernel.org
Cc: Andre Przywara <andre.przywara@arm.com>,
paulus@ozlabs.org, borntraeger@de.ibm.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 2/2] KVM: Protect device ops->create and list_add with kvm->lock
Date: Tue, 9 Aug 2016 14:37:43 +0200 [thread overview]
Message-ID: <27023cbf-294f-b316-97ef-8da4e726cc98@redhat.com> (raw)
In-Reply-To: <20160809122035.16196-3-christoffer.dall@linaro.org>
On 09/08/2016 14:20, Christoffer Dall wrote:
> KVM devices were manipulating list data structures without any form of
> synchronization, and some implementations of the create operations also
> suffered from a lack of synchronization.
>
> Now when we've split the xics create operation into create and init, we
> can hold the kvm->lock mutex while calling the create operation and when
> manipulating the devices list.
>
> The error path in the generic code gets slightly ugly because we have to
> take the mutex again and delete the device from the list, but holding
> the mutex during anon_inode_getfd or releasing/locking the mutex in the
> common non-error path seemed wrong.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Very nice (and small), but please add a comment to the create member in
kvm_device_ops.
Thanks,
Paolo
> ---
> arch/arm/kvm/arm.c | 6 +++++-
> arch/powerpc/kvm/book3s_xics.c | 2 --
> virt/kvm/arm/vgic/vgic-init.c | 17 ++++-------------
> virt/kvm/kvm_main.c | 13 ++++++++++++-
> 4 files changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index d94bb90..75f130e 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -1009,9 +1009,13 @@ long kvm_arch_vm_ioctl(struct file *filp,
>
> switch (ioctl) {
> case KVM_CREATE_IRQCHIP: {
> + int ret;
> if (!vgic_present)
> return -ENXIO;
> - return kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
> + mutex_lock(&kvm->lock);
> + ret = kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
> + mutex_unlock(&kvm->lock);
> + return ret;
> }
> case KVM_ARM_SET_DEVICE_ADDR: {
> struct kvm_arm_device_addr dev_addr;
> diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
> index f2def8e..05aa113 100644
> --- a/arch/powerpc/kvm/book3s_xics.c
> +++ b/arch/powerpc/kvm/book3s_xics.c
> @@ -1329,12 +1329,10 @@ static int kvmppc_xics_create(struct kvm_device *dev, u32 type)
> xics->kvm = kvm;
>
> /* Already there ? */
> - mutex_lock(&kvm->lock);
> if (kvm->arch.xics)
> ret = -EEXIST;
> else
> kvm->arch.xics = xics;
> - mutex_unlock(&kvm->lock);
>
> if (ret) {
> kfree(xics);
> diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
> index fb4b0a7..83777c1 100644
> --- a/virt/kvm/arm/vgic/vgic-init.c
> +++ b/virt/kvm/arm/vgic/vgic-init.c
> @@ -73,12 +73,8 @@ int kvm_vgic_create(struct kvm *kvm, u32 type)
> int i, vcpu_lock_idx = -1, ret;
> struct kvm_vcpu *vcpu;
>
> - mutex_lock(&kvm->lock);
> -
> - if (irqchip_in_kernel(kvm)) {
> - ret = -EEXIST;
> - goto out;
> - }
> + if (irqchip_in_kernel(kvm))
> + return -EEXIST;
>
> /*
> * This function is also called by the KVM_CREATE_IRQCHIP handler,
> @@ -87,10 +83,8 @@ int kvm_vgic_create(struct kvm *kvm, u32 type)
> * the proper checks already.
> */
> if (type == KVM_DEV_TYPE_ARM_VGIC_V2 &&
> - !kvm_vgic_global_state.can_emulate_gicv2) {
> - ret = -ENODEV;
> - goto out;
> - }
> + !kvm_vgic_global_state.can_emulate_gicv2)
> + return -ENODEV;
>
> /*
> * Any time a vcpu is run, vcpu_load is called which tries to grab the
> @@ -138,9 +132,6 @@ out_unlock:
> vcpu = kvm_get_vcpu(kvm, vcpu_lock_idx);
> mutex_unlock(&vcpu->mutex);
> }
> -
> -out:
> - mutex_unlock(&kvm->lock);
> return ret;
> }
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ae64245..1950782 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -696,6 +696,11 @@ static void kvm_destroy_devices(struct kvm *kvm)
> {
> struct kvm_device *dev, *tmp;
>
> + /*
> + * We do not need to take the kvm->lock here, because nobody else
> + * has a reference to the struct kvm at this point and therefore
> + * cannot access the devices list anyhow.
> + */
> list_for_each_entry_safe(dev, tmp, &kvm->devices, vm_node) {
> list_del(&dev->vm_node);
> dev->ops->destroy(dev);
> @@ -2832,11 +2837,15 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
> dev->ops = ops;
> dev->kvm = kvm;
>
> + mutex_lock(&kvm->lock);
> ret = ops->create(dev, cd->type);
> if (ret < 0) {
> + mutex_unlock(&kvm->lock);
> kfree(dev);
> return ret;
> }
> + list_add(&dev->vm_node, &kvm->devices);
> + mutex_unlock(&kvm->lock);
>
> if (ops->init)
> ops->init(dev);
> @@ -2844,10 +2853,12 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
> ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR | O_CLOEXEC);
> if (ret < 0) {
> ops->destroy(dev);
> + mutex_lock(&kvm->lock);
> + list_del(&dev->vm_node);
> + mutex_unlock(&kvm->lock);
> return ret;
> }
>
> - list_add(&dev->vm_node, &kvm->devices);
> kvm_get_kvm(kvm);
> cd->fd = ret;
> return 0;
>
next prev parent reply other threads:[~2016-08-09 12:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 12:20 [PATCH 0/2] KVM: Synchronize KVM devices list access and create ops Christoffer Dall
2016-08-09 12:20 ` [PATCH 1/2] KVM: PPC: Move xics_debugfs_init out of create Christoffer Dall
2016-08-09 12:20 ` [PATCH 2/2] KVM: Protect device ops->create and list_add with kvm->lock Christoffer Dall
2016-08-09 12:37 ` Paolo Bonzini [this message]
2016-08-09 12:55 ` Christoffer Dall
2016-08-09 13:16 ` Paolo Bonzini
2016-08-09 14:49 ` Christoffer Dall
2016-08-09 15:20 ` 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=27023cbf-294f-b316-97ef-8da4e726cc98@redhat.com \
--to=pbonzini@redhat.com \
--cc=andre.przywara@arm.com \
--cc=borntraeger@de.ibm.com \
--cc=christoffer.dall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=paulus@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).