From: Collin Walling <walling@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>, Cornelia Huck <cohuck@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2 4/6] s390x/pci: Ignore the unplug call if we already have a release_timer
Date: Tue, 15 Jan 2019 17:53:17 -0500 [thread overview]
Message-ID: <e897906c-9e69-16e2-9039-1e55fbac576e@linux.ibm.com> (raw)
In-Reply-To: <20190114103110.10909-5-david@redhat.com>
On 1/14/19 5:31 AM, David Hildenbrand wrote:
> ... otherwise two successive calls to qdev_unplug() (e.g. by an impatient
> user) will effectively overwrite pbdev->release_timer, resulting in a
> memory leak. We are already processing the unplug.
>
Does QEMU not have a way to detect if a device is already in the process
of being unplugged? Seems like not having that kind of protection could
cause many problems.
Perhaps that effort would be arduous.
> If there is already a release_timer, the unplug will be performed after
> the timeout.
>
> Can be easily triggered by
> (hmp) device_add virtio-mouse-pci,id=test
> (hmp) stop
> (hmp) device_del test
> (hmp) device_del test
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> hw/s390x/s390-pci-bus.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 59325cae3b..34a9cb2a80 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -972,6 +972,9 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
> case ZPCI_FS_STANDBY:
> break;
> default:
> + if (pbdev->release_timer) {
> + return;
> + }
> s390_pci_generate_plug_event(HP_EVENT_DECONFIGURE_REQUEST,
> pbdev->fh, pbdev->fid);
> pbdev->release_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
>
Looks good to me.
Reviewed-by: Collin Walling <walling@linux.ibm.com>
next prev parent reply other threads:[~2019-01-15 22:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 10:31 [Qemu-devel] [PATCH v2 0/6] s390x/pci: hotplug handler fixes and reworks David Hildenbrand
2019-01-14 10:31 ` [Qemu-devel] [PATCH v2 1/6] s390x/pci: Use hotplug_dev instead of looking up the host bridge David Hildenbrand
2019-01-15 20:57 ` Collin Walling
2019-01-16 9:22 ` Cornelia Huck
2019-01-14 10:31 ` [Qemu-devel] [PATCH v2 2/6] s390x/pci: Move some hotplug checks to the pre_plug handler David Hildenbrand
2019-01-14 10:31 ` [Qemu-devel] [PATCH v2 3/6] s390x/pci: Always delete and free the release_timer David Hildenbrand
2019-01-15 22:43 ` Collin Walling
2019-01-14 10:31 ` [Qemu-devel] [PATCH v2 4/6] s390x/pci: Ignore the unplug call if we already have a release_timer David Hildenbrand
2019-01-15 22:53 ` Collin Walling [this message]
2019-01-16 9:37 ` Cornelia Huck
2019-01-16 9:38 ` David Hildenbrand
2019-01-14 10:31 ` [Qemu-devel] [PATCH v2 5/6] s390x/pci: Introduce unplug requests and split unplug handler David Hildenbrand
2019-01-14 10:31 ` [Qemu-devel] [PATCH v2 6/6] s390x/pci: Unplug remaining devices on pcihost reset David Hildenbrand
2019-01-16 10:19 ` [Qemu-devel] [PATCH v2 0/6] s390x/pci: hotplug handler fixes and reworks Cornelia Huck
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=e897906c-9e69-16e2-9039-1e55fbac576e@linux.ibm.com \
--to=walling@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@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.