From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WugmS-00014u-TM for qemu-devel@nongnu.org; Wed, 11 Jun 2014 07:33:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WugmM-0006bV-87 for qemu-devel@nongnu.org; Wed, 11 Jun 2014 07:33:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WugmM-0006bA-0S for qemu-devel@nongnu.org; Wed, 11 Jun 2014 07:33:18 -0400 Message-ID: <53983E78.1020807@redhat.com> Date: Wed, 11 Jun 2014 13:33:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <97a5753d0e2e5d8ce43730fb0d8595ceb69261a9.1401151094.git.peter.crosthwaite@xilinx.com> <53980F98.9090000@suse.de> <53983D4B.10304@suse.de> In-Reply-To: <53983D4B.10304@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom v1 1/1] qom: object: remove parent pointer when unparenting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Peter Crosthwaite Cc: Kevin Wolf , "qemu-devel@nongnu.org Developers" , Stefan Hajnoczi Il 11/06/2014 13:28, Andreas F=C3=A4rber ha scritto: > Am 11.06.2014 12:19, schrieb Peter Crosthwaite: >> On Wed, Jun 11, 2014 at 6:13 PM, Andreas F=C3=A4rber wrote: >>> Am 27.05.2014 02:39, schrieb Peter Crosthwaite: >>>> Certain parts of the QOM framework test this pointer to determine if >>>> an object is parented. Nuke it when the object is unparented to allo= w >>>> for reuse of an object after unparenting. >>>> >>>> Signed-off-by: Peter Crosthwaite >>>> --- >>>> >>>> qom/object.c | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/qom/object.c b/qom/object.c >>>> index e42b254..8319e89 100644 >>>> --- a/qom/object.c >>>> +++ b/qom/object.c >>>> @@ -402,6 +402,7 @@ void object_unparent(Object *obj) >>>> if (obj->parent) { >>>> object_property_del_child(obj->parent, obj, NULL); >>>> } >>>> + obj->parent =3D NULL; >>>> object_unref(obj); >>>> } >>>> >>> >>> This looks okay to me, and it might also help the segfault on hot-unp= lug >>> Stefan and Kevin reported before I went on travels. >>> >> >> Welcome back. >> >>> Any objection to moving this one line up into the if? >>> >> >> No problem. Will respin. > > I've done so myself, but now I wonder why we are checking obj->parent a= t > all there after we already return if !obj->parent? Is this to guard > against ObjectClass::unparent() changing Object::parent? Either way, th= e > two variants you posted and I suggested should be fine. Yes, in case unparent might already end up removing the property. I have a patch that moves the unparent call to=20 object_finalize_child_property and only removes the property here. The=20 patch would apply anyway, so I'm okay with it. Paolo