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