From: "Andreas Färber" <afaerber@suse.de>
To: Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qdev: free qemu-opts when the QOM path goes away
Date: Thu, 5 Nov 2015 13:06:01 +0100 [thread overview]
Message-ID: <563B4629.10903@suse.de> (raw)
In-Reply-To: <87ziytehr2.fsf@blackfin.pond.sub.org>
Am 04.11.2015 um 19:34 schrieb Markus Armbruster:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
>> Otherwise there is a race where the DEVICE_DELETED event has been sent but
>> attempts to reuse the ID will fail.
>>
>> Reported-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>
> Let's see whether I understand this.
>
>> ---
>> hw/core/qdev.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
>> index 4ab04aa..92bd8bb 100644
>> --- a/hw/core/qdev.c
>> +++ b/hw/core/qdev.c
>> @@ -1203,7 +1203,6 @@ static void device_finalize(Object *obj)
>> NamedGPIOList *ngl, *next;
>>
>> DeviceState *dev = DEVICE(obj);
>> - qemu_opts_del(dev->opts);
>>
>> QLIST_FOREACH_SAFE(ngl, &dev->gpios, node, next) {
>> QLIST_REMOVE(ngl, node);
>> @@ -1251,6 +1250,9 @@ static void device_unparent(Object *obj)
>> qapi_event_send_device_deleted(!!dev->id, dev->id, path, &error_abort);
>
> DEVICE_DELETED sent here.
>
>> g_free(path);
>> }
>> +
>> + qemu_opts_del(dev->opts);
>> + dev->opts = NULL;
>> }
>>
>> static void device_class_init(ObjectClass *class, void *data)
>
> object_finalize_child_property() runs during unplug:
>
> static void object_finalize_child_property(Object *obj, const char *name,
> void *opaque)
> {
> Object *child = opaque;
>
> if (child->class->unparent) {
> (child->class->unparent)(child); <--- calls device_unparent()
> }
> child->parent = NULL;
> object_unref(child); <--- calls device_finalize()
> }
>
> device_unparent() sends DEVICE_DELETED, but dev->opts gets only deleted
> later, in device_finalize. If the client tries to reuse the ID in the
> meantime, it fails.
>
> Two remarks:
>
> 1. Wouldn't it be cleaner to delete dev-opts *before* sending
> DEVICE_DELETED? Like this:
>
> +++ b/hw/core/qdev.c
> @@ -1244,6 +1244,9 @@ static void device_unparent(Object *obj)
> dev->parent_bus = NULL;
> }
>
> + qemu_opts_del(dev->opts);
> + dev->opts = NULL;
> +
> /* Only send event if the device had been completely realized */
> if (dev->pending_deleted_event) {
> gchar *path = object_get_canonical_path(OBJECT(dev));
To me this proposal sounds sane, but I did not get to tracing the code
flow here. Paolo, which approach do you prefer and why?
> 2. If the device is a block device, then unplugging it also deletes its
> backend (ugly wart we keep for backward compatibility; *not* for
> blockdev-add, though). This backend also has a QemuOpts. It gets
> deleted in drive_info_del(). Just like device_finalize(), it runs
> within object_unref(), i.e. after DEVICE_DELETED is sent. Same race,
> different ID, or am I missing something?
>
> See also https://bugzilla.redhat.com/show_bug.cgi?id=1256044
If we can leave this patch decoupled from block layer and decide soonish
on the desired approach, I'd be happy to include it in my upcoming
qom-devices pull.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2015-11-05 12:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 11:11 [Qemu-devel] [PATCH] qdev: free qemu-opts when the QOM path goes away Paolo Bonzini
2015-11-04 15:53 ` Paolo Bonzini
2015-11-04 18:34 ` Markus Armbruster
2015-11-05 12:06 ` Andreas Färber [this message]
2015-11-05 12:21 ` Paolo Bonzini
2015-11-05 12:47 ` Markus Armbruster
2016-01-15 17:03 ` Andreas Färber
2016-01-15 17:16 ` Paolo Bonzini
2016-01-15 17:36 ` Andreas Färber
2016-01-18 9:45 ` Markus Armbruster
2016-01-08 18:17 ` 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=563B4629.10903@suse.de \
--to=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@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 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).