From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNMMr-00007j-D1 for qemu-devel@nongnu.org; Wed, 13 Jul 2016 11:46:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNMMo-0003t5-KP for qemu-devel@nongnu.org; Wed, 13 Jul 2016 11:46:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNMMo-0003t0-EZ for qemu-devel@nongnu.org; Wed, 13 Jul 2016 11:46:30 -0400 Date: Wed, 13 Jul 2016 17:46:25 +0200 From: Igor Mammedov Message-ID: <20160713174625.3c40a9a8@nial.brq.redhat.com> In-Reply-To: <20160713172618.718e83b6@nial.brq.redhat.com> References: <1467786055-85835-1-git-send-email-imammedo@redhat.com> <1467786055-85835-18-git-send-email-imammedo@redhat.com> <20160713150444.GK3727@thinpad.lan.raisama.net> <20160713172618.718e83b6@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 17/19] target-i386: fix apic object leak when CPU is deleted List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: pkrempa@redhat.com, mst@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, eduardo.otubo@profitbricks.com, marcel@redhat.com, pbonzini@redhat.com, rth@twiddle.net On Wed, 13 Jul 2016 17:26:18 +0200 Igor Mammedov wrote: > On Wed, 13 Jul 2016 12:04:44 -0300 > Eduardo Habkost wrote: > > > On Wed, Jul 06, 2016 at 08:20:53AM +0200, Igor Mammedov wrote: > > > Signed-off-by: Igor Mammedov > > > --- > > > 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 Well, I've wrote nonsense here as I do remove child explicitly in x86_cpu_unrealizefn(), so it's fine to set cpu->apic_state to NULL as you suggest in 18/19. The other way around might be call only apic_state->unrealize() explicitly from x86_cpu_unrealizefn() and let QOM do unparenting/finalizing automatically for us. I'd even prefer this one over the former. Which one would you prefer? > I don't see how it could be deleted by other code path. That point still stands. > > > 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 > > > > > > >