Re: [Qemu-devel] [PATCH for-2.8 1/2] monitor: fix object_del for command-line-created objects

[Michael Roth <mdroth@linux.vnet.ibm.com>]

Quoting Markus Armbruster (2016-12-07 04:36:20)
> Michael Roth <mdroth@linux.vnet.ibm.com> writes:
> 
> > Currently objects specified on the command-line are only partially
> > cleaned up when 'object_del' is issued in either HMP or QMP: the
> > object itself is fully finalized, but the QemuOpts are not removed.
> > This results in the following behavior:
> >
> >   x86_64-softmmu/qemu-system-x86_64 -monitor stdio \
> >     -object memory-backend-ram,id=ram1,size=256M
> >
> >   QEMU 2.7.91 monitor - type 'help' for more information
> >   (qemu) object_del ram1
> >   (qemu) object_del ram1
> >   object 'ram1' not found
> >   (qemu) object_add memory-backend-ram,id=ram1,size=256M
> >   Duplicate ID 'ram1' for object
> >   Try "help object_add" for more information
> >
> > which can be an issue for use-cases like memory hotplug.
> >
> > This happens on the HMP side because hmp_object_add() attempts to
> > create a temporary QemuOpts entry with ID 'ram1', which ends up
> > conflicting with the command-line-created entry, since it was never
> > cleaned up during the previous hmp_object_del() call.
> >
> > We address this by adding a check in user_creatable_del(), which
> > is called by both qmp_object_del() and hmp_object_del() to handle
> > the actual object cleanup, to determine whether an option group entry
> > matching the object's ID is present and removing it if it is.
> >
> > Note that qmp_object_add() never attempts to create a temporary
> > QemuOpts entry, so it does not encounter the duplicate ID error,
> > which is why this isn't generally visible in libvirt.
> >
> > Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > Cc: Markus Armbruster <armbru@redhat.com>
> > Cc: Eric Blake <eblake@redhat.com>
> > Cc: Daniel Berrange <berrange@redhat.com>
> > Cc: qemu-stable@nongnu.org
> > Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> > ---
> >  qom/object_interfaces.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
> > index ded4d84..23849f9 100644
> > --- a/qom/object_interfaces.c
> > +++ b/qom/object_interfaces.c
> > @@ -5,6 +5,7 @@
> >  #include "qapi-visit.h"
> >  #include "qapi/qobject-output-visitor.h"
> >  #include "qapi/opts-visitor.h"
> > +#include "qemu/config-file.h"
> >  
> >  void user_creatable_complete(Object *obj, Error **errp)
> >  {
> > @@ -197,6 +198,7 @@ void user_creatable_del(const char *id, Error **errp)
> >  {
> >      Object *container;
> >      Object *obj;
> > +    QemuOptsList *opt_group;
> >  
> >      container = object_get_objects_root();
> >      obj = object_resolve_path_component(container, id);
> > @@ -209,6 +211,15 @@ void user_creatable_del(const char *id, Error **errp)
> >          error_setg(errp, "object '%s' is in use, can not be deleted", id);
> >          return;
> >      }
> > +
> > +    /* if object was defined on the command-line, remove its corresponding
> > +     * option group entry
> > +     */
> > +    opt_group = qemu_find_opts_err("object", NULL);
> > +    if (opt_group) {
> 
> How can opt_group ever be null?
> 
> For what it's worth, we assume it can't in hmp_object_add() and main().

I was trying to avoid as many assumptions as possible since
user_creatable_complete() is kind of reaching out of it's scope here.
If we ever changed the behavior on the parsing side this could result in
a segfault that might slip through if this particular scenario isn't
specifically tested.

However, that's less of a concern now thanks to the unit tests that
Daniel suggested which would catch this breakage. So that kind of handles
my concerns. Will change it for v3.

> 
> > +        qemu_opts_del(qemu_opts_find(opt_group, id));
> > +    }
> > +
> >      object_unparent(obj);
> >  }
>