From: Paul Mackerras <paulus@ozlabs.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: kvm-ppc@vger.kernel.org,
David Gibson <david@gibson.dropbear.id.au>,
kvm@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v5 16/16] KVM: PPC: Book3S HV: XIVE: introduce a 'release' device operation
Date: Thu, 11 Apr 2019 10:27:10 +0000 [thread overview]
Message-ID: <20190411102710.GD21252@blackberry> (raw)
In-Reply-To: <20190410170448.3923-17-clg@kaod.org>
On Wed, Apr 10, 2019 at 07:04:48PM +0200, Cédric Le Goater wrote:
> When a P9 sPAPR VM boots, the CAS negotiation process determines which
> interrupt mode to use (XICS legacy or XIVE native) and invokes a
> machine reset to activate the chosen mode.
>
> To be able to switch from one mode to another, we introduce the
> capability to release a KVM device without destroying the VM. The KVM
> device interface is extended with a new 'release' operation which is
> called when the file descriptor of the device is closed.
Unfortunately, I think there is now a memory leak:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ea2018ae1cd7..ea2619d5ca98 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2938,6 +2938,19 @@ static int kvm_device_release(struct inode *inode, struct file *filp)
> struct kvm_device *dev = filp->private_data;
> struct kvm *kvm = dev->kvm;
>
> + if (!dev)
> + return -ENODEV;
> +
> + if (dev->kvm != kvm)
> + return -EPERM;
> +
> + if (dev->ops->release) {
> + mutex_lock(&kvm->lock);
> + list_del(&dev->vm_node);
Because the device is now no longer in the kvm->devices list,
kvm_destroy_devices() won't find it there and therefore won't call the
device's destroy method. In fact now the device's destroy method will
never get called; I can't see how kvmppc_xive_free() or
kvmppc_xive_native_free() will ever get called. Thus the memory for
the kvmppc_xive structs will never get freed as far as I can see.
We could fix that by freeing both of the kvm->arch.xive_devices
entries at VM destruction time.
If it is true that any device that has a release method will never see
its destroy method being called, then that needs to be documented
clearly somewhere.
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,
Paolo Bonzini <pbonzini@redhat.com>,
linuxppc-dev@lists.ozlabs.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v5 16/16] KVM: PPC: Book3S HV: XIVE: introduce a 'release' device operation
Date: Thu, 11 Apr 2019 20:27:10 +1000 [thread overview]
Message-ID: <20190411102710.GD21252@blackberry> (raw)
In-Reply-To: <20190410170448.3923-17-clg@kaod.org>
On Wed, Apr 10, 2019 at 07:04:48PM +0200, Cédric Le Goater wrote:
> When a P9 sPAPR VM boots, the CAS negotiation process determines which
> interrupt mode to use (XICS legacy or XIVE native) and invokes a
> machine reset to activate the chosen mode.
>
> To be able to switch from one mode to another, we introduce the
> capability to release a KVM device without destroying the VM. The KVM
> device interface is extended with a new 'release' operation which is
> called when the file descriptor of the device is closed.
Unfortunately, I think there is now a memory leak:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ea2018ae1cd7..ea2619d5ca98 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2938,6 +2938,19 @@ static int kvm_device_release(struct inode *inode, struct file *filp)
> struct kvm_device *dev = filp->private_data;
> struct kvm *kvm = dev->kvm;
>
> + if (!dev)
> + return -ENODEV;
> +
> + if (dev->kvm != kvm)
> + return -EPERM;
> +
> + if (dev->ops->release) {
> + mutex_lock(&kvm->lock);
> + list_del(&dev->vm_node);
Because the device is now no longer in the kvm->devices list,
kvm_destroy_devices() won't find it there and therefore won't call the
device's destroy method. In fact now the device's destroy method will
never get called; I can't see how kvmppc_xive_free() or
kvmppc_xive_native_free() will ever get called. Thus the memory for
the kvmppc_xive structs will never get freed as far as I can see.
We could fix that by freeing both of the kvm->arch.xive_devices
entries at VM destruction time.
If it is true that any device that has a release method will never see
its destroy method being called, then that needs to be documented
clearly somewhere.
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-ppc@vger.kernel.org,
David Gibson <david@gibson.dropbear.id.au>,
kvm@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v5 16/16] KVM: PPC: Book3S HV: XIVE: introduce a 'release' device operation
Date: Thu, 11 Apr 2019 20:27:10 +1000 [thread overview]
Message-ID: <20190411102710.GD21252@blackberry> (raw)
In-Reply-To: <20190410170448.3923-17-clg@kaod.org>
On Wed, Apr 10, 2019 at 07:04:48PM +0200, Cédric Le Goater wrote:
> When a P9 sPAPR VM boots, the CAS negotiation process determines which
> interrupt mode to use (XICS legacy or XIVE native) and invokes a
> machine reset to activate the chosen mode.
>
> To be able to switch from one mode to another, we introduce the
> capability to release a KVM device without destroying the VM. The KVM
> device interface is extended with a new 'release' operation which is
> called when the file descriptor of the device is closed.
Unfortunately, I think there is now a memory leak:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ea2018ae1cd7..ea2619d5ca98 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2938,6 +2938,19 @@ static int kvm_device_release(struct inode *inode, struct file *filp)
> struct kvm_device *dev = filp->private_data;
> struct kvm *kvm = dev->kvm;
>
> + if (!dev)
> + return -ENODEV;
> +
> + if (dev->kvm != kvm)
> + return -EPERM;
> +
> + if (dev->ops->release) {
> + mutex_lock(&kvm->lock);
> + list_del(&dev->vm_node);
Because the device is now no longer in the kvm->devices list,
kvm_destroy_devices() won't find it there and therefore won't call the
device's destroy method. In fact now the device's destroy method will
never get called; I can't see how kvmppc_xive_free() or
kvmppc_xive_native_free() will ever get called. Thus the memory for
the kvmppc_xive structs will never get freed as far as I can see.
We could fix that by freeing both of the kvm->arch.xive_devices
entries at VM destruction time.
If it is true that any device that has a release method will never see
its destroy method being called, then that needs to be documented
clearly somewhere.
Paul.
next prev parent reply other threads:[~2019-04-11 10:27 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 17:04 [PATCH v5 00/16] KVM: PPC: Book3S HV: add XIVE native exploitation mode Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 01/16] powerpc/xive: add OPAL extensions for the XIVE native exploitation support Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-05-03 6:50 ` Michael Ellerman
2019-05-03 6:50 ` Michael Ellerman
2019-05-03 6:50 ` Michael Ellerman
2019-04-10 17:04 ` [PATCH v5 02/16] KVM: PPC: Book3S HV: add a new KVM device for the XIVE native exploitation mode Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 03/16] KVM: PPC: Book3S HV: XIVE: introduce a new capability KVM_CAP_PPC_IRQ_XIVE Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 04/16] KVM: PPC: Book3S HV: XIVE: add a control to initialize a source Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 05/16] KVM: PPC: Book3S HV: XIVE: add a control to configure " Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 06/16] KVM: PPC: Book3S HV: XIVE: add controls for the EQ configuration Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-12 5:19 ` David Gibson
2019-04-12 5:19 ` David Gibson
2019-04-12 5:19 ` David Gibson
2019-04-10 17:04 ` [PATCH v5 07/16] KVM: PPC: Book3S HV: XIVE: add a global reset control Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 08/16] KVM: PPC: Book3S HV: XIVE: add a control to sync the sources Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 09/16] KVM: PPC: Book3S HV: XIVE: add a control to dirty the XIVE EQ pages Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 10/16] KVM: PPC: Book3S HV: XIVE: add get/set accessors for the VP XIVE state Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 11/16] KVM: introduce a 'mmap' method for KVM devices Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 12/16] KVM: PPC: Book3S HV: XIVE: add a TIMA mapping Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 13/16] KVM: PPC: Book3S HV: XIVE: add a mapping for the source ESB pages Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 14/16] KVM: PPC: Book3S HV: XIVE: add passthrough support Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 15/16] KVM: PPC: Book3S HV: XIVE: activate XIVE exploitation mode Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` [PATCH v5 16/16] KVM: PPC: Book3S HV: XIVE: introduce a 'release' device operation Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-10 17:04 ` Cédric Le Goater
2019-04-11 3:16 ` Paul Mackerras
2019-04-11 3:16 ` Paul Mackerras
2019-04-11 3:16 ` Paul Mackerras
2019-04-11 4:38 ` David Gibson
2019-04-11 4:38 ` David Gibson
2019-04-11 4:38 ` David Gibson
2019-04-11 6:12 ` Cédric Le Goater
2019-04-11 6:12 ` Cédric Le Goater
2019-04-11 6:12 ` Cédric Le Goater
2019-04-11 10:27 ` Paul Mackerras [this message]
2019-04-11 10:27 ` Paul Mackerras
2019-04-11 10:27 ` Paul Mackerras
2019-04-11 11:48 ` Cédric Le Goater
2019-04-11 11:48 ` Cédric Le Goater
2019-04-11 11:48 ` Cédric Le Goater
2019-04-29 8:05 ` [PATCH v5 00/16] KVM: PPC: Book3S HV: add XIVE native exploitation mode Satheesh Rajendran
2019-04-29 8:17 ` Satheesh Rajendran
2019-04-29 8:05 ` Satheesh Rajendran
2019-05-06 16:21 ` Cédric Le Goater
2019-05-06 16:21 ` Cédric Le Goater
2019-05-06 16:21 ` Cédric Le Goater
2019-05-09 6:34 ` Cédric Le Goater
2019-05-09 6:34 ` Cédric Le Goater
2019-05-09 6:34 ` Cédric Le Goater
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=20190411102710.GD21252@blackberry \
--to=paulus@ozlabs.org \
--cc=clg@kaod.org \
--cc=david@gibson.dropbear.id.au \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--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.