From: SeokYeon Hwang <syeon.hwang@samsung.com>
To: marcel.a@redhat.com
Cc: qemu-devel@nongnu.org, "'Michael S. Tsirkin'" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pci: add checking whether the device is realized before unlinking the capability
Date: Thu, 26 Jun 2014 12:48:14 +0900 [thread overview]
Message-ID: <007a01cf90f1$752d87f0$5f8897d0$@samsung.com> (raw)
In-Reply-To: <1403699312.20031.46.camel@localhost.localdomain>
> On Wed, 2014-06-25 at 15:03 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 25, 2014 at 06:59:08PM +0900, SeokYeon Hwang wrote:
> > > In case of the unrealized "pdev", memory can be illegally accessed and
> corrupted.
> > > Refer to device_unparent() in the commit
> 5c21ce77d7e5643089ceec556c0408445d017f32.
> Hi,
> Thank you for submitting the patch.
>
> Can you please send to the list how to reproduce the issue?
> Is this a regression? Before the above commit did it work?
Hi,
When VirtIO device is hot-unplugged, Qemu unrealizes the device first then child_bus by device_unparent().
(After the commit 5c21ce77d7e5643089ceec556c0408445d017f32.)
For example, if I suppose to hot-unplug "virtio block" device, unparent "virtio-blk-pci" first, then "virtio-blk".
virtio_bus_device_unplugged() function in virtio-bus.c calls "msix_uninit()" with the parameter of its parent PCI device.
The problem is that it accesses already freed member of pdev, such as "pdev->config".
This illegal access causes the heap corruption, and it kills Qemu process suddenly.
You can detect this illegal access by using "electric fence" or "valgrind".
>
> > >
> > > Change-Id: Iacb195a092c86d4c677ad0404582af104b2251ae
> > > Signed-off-by: SeokYeon Hwang <syeon.hwang@samsung.com>
> >
> > Another case of qemu mailing list dropping patches :( I will bounce it
> > now so people can see the original message.
> >
> >
> > > ---
> > > hw/pci/pci.c | 7 ++++++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 49eca95..bb7f0c5
> > > 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -2056,7 +2056,12 @@ int pci_add_capability(PCIDevice *pdev,
> > > uint8_t cap_id,
> > > /* Unlink capability from the pci config space. */ void
> > > pci_del_capability(PCIDevice *pdev, uint8_t cap_id, uint8_t size) {
> > > - uint8_t prev, offset = pci_find_capability_list(pdev, cap_id,
> &prev);
> > > + uint8_t prev, offset;
> > > + /* Check whether the device is realized or not */
> > > + if (!pdev->qdev.realized) {
> The 'qdev' field and 'realize' property are private, you should use one of
> QOM's 'property_get' methods.
>
> I am also concerned about adding the realize check here, it seems too
> "deep" in implementation, seeing this checks everywhere doesn't seem a
> good idea.
> I think we should first understand the root cause and try making this
> change in a higher level.
>
> I hope I helped,
> Marcel
Ok, I see. I think you're right.
If needed, I will send an another patch using "object_property_get_bool()".
Thanks.
>
>
> > > + return;
> > > + }
> > > + offset = pci_find_capability_list(pdev, cap_id, &prev);
> > > if (!offset)
> > > return;
> > > pdev->config[prev] = pdev->config[offset + PCI_CAP_LIST_NEXT];
> > > --
> > > 1.9.1
> >
>
next prev parent reply other threads:[~2014-06-26 3:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 9:59 [Qemu-devel] [PATCH] pci: add checking whether the device is realized before unlinking the capability SeokYeon Hwang
2014-06-25 12:03 ` Michael S. Tsirkin
2014-06-25 12:28 ` Marcel Apfelbaum
2014-06-26 3:48 ` SeokYeon Hwang [this message]
2014-06-26 7:07 ` Michael S. Tsirkin
2014-06-28 6:39 ` SeokYeon Hwang
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='007a01cf90f1$752d87f0$5f8897d0$@samsung.com' \
--to=syeon.hwang@samsung.com \
--cc=marcel.a@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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.