qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <dahi@linux.vnet.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	ehabkost@redhat.com,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	qemu-devel@nongnu.org, qemu-stable@nongnu.org,
	Alexander Graf <agraf@suse.de>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-ppc@nongnu.org, Antony Pavlov <antonynpavlov@gmail.com>,
	stefanha@redhat.com, Cornelia Huck <cornelia.huck@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alistair Francis <alistair.francis@xilinx.com>,
	afaerber@suse.de, Li Guang <lig.fnst@cn.fujitsu.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 5/7] qdev: Protect device-list-properties against broken devices
Date: Mon, 21 Sep 2015 10:30:50 +0200	[thread overview]
Message-ID: <20150921103050.02ca68f8@thinkpad-w530> (raw)
In-Reply-To: <55FC05B7.9080902@de.ibm.com>

> Am 18.09.2015 um 14:00 schrieb Markus Armbruster:
> > Several devices don't survive object_unref(object_new(T)): they crash
> > or hang during cleanup, or they leave dangling pointers behind.
> > 
> > This breaks at least device-list-properties, because
> > qmp_device_list_properties() needs to create a device to find its
> > properties.  Broken in commit f4eb32b "qmp: show QOM properties in
> > device-list-properties", v2.1.  Example reproducer:
> > 
> >     $ qemu-system-aarch64 -nodefaults -display none -machine none -S -qmp stdio
> >     {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2}, "package": ""}, "capabilities": []}}
> >     { "execute": "qmp_capabilities" }
> >     {"return": {}}
> >     { "execute": "device-list-properties", "arguments": { "typename": "pxa2xx-pcmcia" } }
> >     qemu-system-aarch64: /home/armbru/work/qemu/memory.c:1307: memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void *)0))' failed.
> >     Aborted (core dumped)
> >     [Exit 134 (SIGABRT)]
> > 
> > Unfortunately, I can't fix the problems in these devices right now.
> > Instead, add DeviceClass member cannot_even_create_with_object_new_yet
> > to mark them:
> > 
> > * Crash or hang during cleanup (didn't debug them, so I can't say
> >   why): "pxa2xx-pcmcia", "realview_pci", "versatile_pci",
> >   "s390-sclp-event-facility", "sclp"
> 
> Ack for the sclp things. Theses devices are created by the machine and
> sclp creates the event-facility, so not having a way to query properties
> for these devices is better than a hang.
> 
> David, can you have a look on why these devices fail as outlined?
> 

The problem was that the quiesce and cpu hotplug sclp event devices had no
parent (onoly a parent bus). So when the bus (inside the event facility) was
removed, it looped forever trying remove/unparent it's "bus childs" (which had
no parent).

sclp (parent=machine)
    -> even-facility (parent=sclp)
                    -> bus (parent=event-facility)
                          -> quiesce (parent=null)
                          -> cpu hotplug (parent=null)

Maybe that helps others struggling with the same symptoms.


Just a quick comment on the introspection:

I don't think it is a good idea to expose properties that way. Temporarily
creating devices for the sake of querying property names sounds very wrong to
me, because certain devices require certain knowledge about how and when they
can be created.

Feels a little like hacking an interface to a java program, which allows to
create any object of a special kind dynamically (constructor arguments?),
reading some member variable (names) via reflections and then throwing that
object away. Which sounds very wrong to me.

Wonder if it wouldn't make more sense to query only the static properties of a
device. I mean if the dynamic properties are dynamic by definition (and can
change during runtime). So looking up the static properties via the typename
feels more KIS-style to me. Of course, the relevant properties would have to be
defined statically then, which shouldn't be a problem.

Dynamic properties that are actually created could depend on almost
everything in the system - why fake something that we don't know.

David

  reply	other threads:[~2015-09-21  8:31 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-18 12:00 [Qemu-devel] [PATCH 0/7] Fix device introspection regressions Markus Armbruster
2015-09-18 12:00 ` [Qemu-devel] [PATCH 1/7] libqtest: Clean up unused QTestState member sigact_old Markus Armbruster
2015-09-18 15:36   ` Eric Blake
2015-09-18 12:00 ` [Qemu-devel] [PATCH 2/7] libqtest: New hmp() & friends Markus Armbruster
2015-09-18 15:47   ` Eric Blake
2015-09-21  5:59     ` Markus Armbruster
2015-09-18 12:00 ` [Qemu-devel] [PATCH 3/7] device-introspect-test: New, covering device introspection Markus Armbruster
2015-09-18 15:55   ` Eric Blake
2015-09-21  6:05     ` Markus Armbruster
2015-09-18 12:00 ` [Qemu-devel] [PATCH 4/7] qmp: Fix device-list-properties not to crash for abstract device Markus Armbruster
2015-09-18 15:58   ` Eric Blake
2015-09-18 12:00 ` [Qemu-devel] [PATCH 5/7] qdev: Protect device-list-properties against broken devices Markus Armbruster
2015-09-18 12:38   ` Christian Borntraeger
2015-09-21  8:30     ` David Hildenbrand [this message]
2015-09-21 15:38       ` Eduardo Habkost
2015-09-22  8:02         ` David Hildenbrand
2015-09-22  8:07         ` Markus Armbruster
2015-09-18 16:09   ` Eric Blake
2015-09-21  6:08     ` Markus Armbruster
2015-09-18 16:36   ` Eduardo Habkost
2015-09-21  6:09     ` Markus Armbruster
2015-09-21 15:13       ` Eduardo Habkost
2015-09-18 18:42   ` Thomas Huth
2015-09-18 19:32     ` Eduardo Habkost
2015-09-21  6:14       ` Markus Armbruster
2015-09-21 15:20         ` Eduardo Habkost
2015-09-21 15:48         ` Thomas Huth
2015-09-21 16:39           ` Markus Armbruster
2015-09-21 17:22             ` Thomas Huth
2015-09-21 18:19               ` Eduardo Habkost
2015-09-18 12:00 ` [Qemu-devel] [PATCH 6/7] Revert "qdev: Use qdev_get_device_class() for -device <type>, help" Markus Armbruster
2015-09-18 16:13   ` Eric Blake
2015-09-18 12:00 ` [Qemu-devel] [PATCH 7/7] tests: Simplify how qom-test is run Markus Armbruster
2015-09-18 12:53   ` Andreas Färber
2015-09-18 14:24     ` Markus Armbruster
2015-09-18 15:28       ` Andreas Färber
2015-09-21  6:15         ` Markus Armbruster
2015-09-23 13:57         ` Markus Armbruster

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=20150921103050.02ca68f8@thinkpad-w530 \
    --to=dahi@linux.vnet.ibm.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=alistair.francis@xilinx.com \
    --cc=antonynpavlov@gmail.com \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=lig.fnst@cn.fujitsu.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=stefanha@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;
as well as URLs for NNTP newsgroup(s).