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 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.