qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qdev: free qemu-opts when the QOM path goes away
Date: Fri, 15 Jan 2016 18:03:39 +0100	[thread overview]
Message-ID: <5699266B.7080209@suse.de> (raw)
In-Reply-To: <87a8qswr33.fsf@blackfin.pond.sub.org>

Am 05.11.2015 um 13:47 schrieb Markus Armbruster:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>> On 05/11/2015 13:06, Andreas Färber wrote:
>>>> 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?
>>
>> It doesn't really matter, because the BQL is being held here.
>>
>> On the other hand, if the opts are deleted in finalize, there is an
>> arbitrary delay because finalize is typically called after a
>> synchronize_rcu period.
>>
>>>>> 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.
>>
>> I agree with you, the block layer bug is separate.
> 
> Related, but clearly separate.  Mentioning it in the commit message
> would be nice, though.

Paolo, pong: I gathered that I should queue the original patch without
Markus's proposed change, correct? And do you want to add some sentence
to the commit message as requested by Markus?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

  reply	other threads:[~2016-01-15 17:03 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
2015-11-05 12:21     ` Paolo Bonzini
2015-11-05 12:47       ` Markus Armbruster
2016-01-15 17:03         ` Andreas Färber [this message]
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=5699266B.7080209@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).