On Wed, 13 Jul 2016 12:04:44 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Wed, Jul 06, 2016 at 08:20:53AM +0200, Igor Mammedov wrote: > > Signed-off-by: Igor Mammedov <imamm...@redhat.com> > > --- > > target-i386/cpu.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > > index 04c0b79..2fa445d 100644 > > --- a/target-i386/cpu.c > > +++ b/target-i386/cpu.c > > @@ -2765,6 +2765,7 @@ static void x86_cpu_apic_create(X86CPU *cpu, Error > > **errp) > > > > object_property_add_child(OBJECT(cpu), "lapic", > > OBJECT(cpu->apic_state), &error_abort); > > + object_unref(OBJECT(cpu->apic_state)); > > What kind of event can trigger object_unparent() or > object_del_property() on "lapic"? Can we guarantee that the child > property will never be deleted by any other code, only by > x86_cpu_unrealizefn() and object_finalize(cpu)? code path that triggers unparent of lapic implicitly is cpu instance removal when it deletes all children. So unless someone adds explicit lapic removal somewhere in target-i386/cpu.c I don't see how it could be deleted by other code path. > Because with this change, deleting the property will leave us > with with a dangling cpu->apic_state pointer. since there aren't other place that deletes lapic property we won't get it dangling pointer, see the next patch comment for call chain > > > > > qdev_prop_set_uint8(cpu->apic_state, "id", cpu->apic_id); > > /* TODO: convert to link<> */ > > -- > > 2.7.0 > > >
