[question] qemu abort when object-add is called with an already used id

[question] qemu abort when object-add is called with an already used id

[Auger Eric]

Hi,

While testing PCDIMM hotplug/coldplug I noted qemu aborts if we attempt
to add from the QMP monitor an object whose id is already in use.

for instance
object-add qom-type=memory-backend-ram id=mem1 props.size=4294967296
while mem1 is already used.

We get:
Unexpected error in object_property_try_add() at qom/object.c:1167:
attempt to add duplicate property 'mem1' to object (type 'container')

This is due to the fact &error_abort is passed to object_property_try_add().

Is it the expected behavior?

Thanks

Eric


Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7fd0e80 (LWP 411617)]
0x00007ffff5a1370f in raise () from /lib64/libc.so.6
(gdb) where
#0  0x00007ffff5a1370f in raise () at /lib64/libc.so.6
#1  0x00007ffff59fdb25 in abort () at /lib64/libc.so.6
#2  0x000055555581e0dc in error_handle_fatal (errp=<optimized out>,
err=0x555556bc40b0) at util/error.c:40
#3  0x0000555555c572ad in error_setv
    (errp=0x555556557b18 <error_abort>, src=0x555555e34ff3
"qom/object.c", line=1167, func=0x555555e35720 <__func__.18519>
"object_property_try_add", err_class=ERROR_CLASS_GENERIC_ERROR,
fmt=<optimized out>, ap=0x7fffffffd7a0, suffix=0x0) at util/error.c:73
#4  0x0000555555c57430 in error_setg_internal
    (errp=errp@entry=0x555556557b18 <error_abort>,
src=src@entry=0x555555e34ff3 "qom/object.c", line=line@entry=1167,
func=func@entry=0x555555e35720 <__func__.18519>
"object_property_try_add", fmt=fmt@entry=0x555555e35438 "attempt to add
duplicate property '%s' to object (type '%s')") at util/error.c:97
#5  0x0000555555b5bf48 in object_property_try_add
    (obj=obj@entry=0x5555567ef280, name=name@entry=0x7ffee4003f80
"mem1", type=type@entry=0x5555573c0dc0 "child<memory-backend-ram>",
get=get@entry=0x555555b5d6b0 <object_get_child_property>,
set=set@entry=0x0, release=release@entry=0x555555b5b930
<object_finalize_child_property>, opaque=0x5555569158a0,
errp=0x555556557b18 <error_abort>) at qom/object.c:1166
#6  0x0000555555b5cf5c in object_property_add
    (opaque=0x5555569158a0, release=0x555555b5b930
<object_finalize_child_property>, set=0x0, get=0x555555b5d6b0
<object_get_child_property>, type=0x5555573c0dc0
"child<memory-backend-ram>", name=0x7ffee4003f80 "mem1",
obj=0x5555567ef280) at qom/object.c:1664
#7  0x0000555555b5cf5c in object_property_add_child (obj=0x5555567ef280,
name=name@entry=0x7ffee4003f80 "mem1", child=child@entry=0x5555569158a0)
at qom/object.c:1664
#8  0x0000555555b5e961 in user_creatable_add_type
    (type=type@entry=0x7ffee4004410 "memory-backend-ram",
id=id@entry=0x7ffee4003f80 "mem1", qdict=qdict@entry=0x7ffee40061d0,
v=v@entry=
    0x55555763d3e0, errp=errp@entry=0x7fffffffd9d8) at
qom/object_interfaces.c:85
#9  0x0000555555b5eb66 in user_creatable_add_dict (qdict=0x7ffee40061d0,
keyval=<optimized out>, errp=0x7fffffffd9d8) at qom/object_interfaces.c:131
#10 0x0000555555c06b70 in qmp_dispatch (cmds=0x555556555620
<qmp_commands>, request=<optimized out>, allow_oob=<optimized out>) at
qapi/qmp-dispatch.c:155
#11 0x0000555555b06d01 in monitor_qmp_dispatch (mon=0x555556823800,
req=<optimized out>) at monitor/qmp.c:145
#12 0x0000555555b0751a in monitor_qmp_bh_dispatcher (data=<optimized
out>) at monitor/qmp.c:234
#13 0x0000555555c622c5 in aio_bh_call (bh=0x5555565da750) at
util/async.c:164
#14 0x0000555555c622c5 in aio_bh_poll (ctx=ctx@entry=0x5555565d92c0) at
util/async.c:164
--Type <RET> for more, q to quit, c to continue without paging--

Re: [question] qemu abort when object-add is called with an already used id

[Daniel P. Berrangé]

On Thu, Jun 18, 2020 at 06:15:57PM +0200, Auger Eric wrote:
> Hi,
> 
> While testing PCDIMM hotplug/coldplug I noted qemu aborts if we attempt
> to add from the QMP monitor an object whose id is already in use.
> 
> for instance
> object-add qom-type=memory-backend-ram id=mem1 props.size=4294967296
> while mem1 is already used.
> 
> We get:
> Unexpected error in object_property_try_add() at qom/object.c:1167:
> attempt to add duplicate property 'mem1' to object (type 'container')
> 
> This is due to the fact &error_abort is passed to object_property_try_add().
> 
> Is it the expected behavior?

No, this is highly undesirable. A user/mgmt app mistake in reusing a
property ID shouldn't result in loss of the entire running VM and the
user's live data within.

We must gracefully report the error back to the QMP client.

error_abort should really only be used in scenarios which are
not expected to happen in real world. eg it is more like an
assert() in terms of where it should be used.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [question] qemu abort when object-add is called with an already used id

[Auger Eric]

Hi Daniel,

On 6/18/20 7:12 PM, Daniel P. Berrangé wrote:
> On Thu, Jun 18, 2020 at 06:15:57PM +0200, Auger Eric wrote:
>> Hi,
>>
>> While testing PCDIMM hotplug/coldplug I noted qemu aborts if we attempt
>> to add from the QMP monitor an object whose id is already in use.
>>
>> for instance
>> object-add qom-type=memory-backend-ram id=mem1 props.size=4294967296
>> while mem1 is already used.
>>
>> We get:
>> Unexpected error in object_property_try_add() at qom/object.c:1167:
>> attempt to add duplicate property 'mem1' to object (type 'container')
>>
>> This is due to the fact &error_abort is passed to object_property_try_add().
>>
>> Is it the expected behavior?
> 
> No, this is highly undesirable. A user/mgmt app mistake in reusing a
> property ID shouldn't result in loss of the entire running VM and the
> user's live data within.
> 
> We must gracefully report the error back to the QMP client.
> 
> error_abort should really only be used in scenarios which are
> not expected to happen in real world. eg it is more like an
> assert() in terms of where it should be used.

OK thank you for the confirmation, I will work on this.

Thanks

Eric
> 
> 
> Regards,
> Daniel
>