From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WughW-0006eO-FY for qemu-devel@nongnu.org; Wed, 11 Jun 2014 07:28:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WughQ-0004a2-SI for qemu-devel@nongnu.org; Wed, 11 Jun 2014 07:28:18 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36918 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WughQ-0004Zl-M1 for qemu-devel@nongnu.org; Wed, 11 Jun 2014 07:28:12 -0400 Message-ID: <53983D4B.10304@suse.de> Date: Wed, 11 Jun 2014 13:28:11 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <97a5753d0e2e5d8ce43730fb0d8595ceb69261a9.1401151094.git.peter.crosthwaite@xilinx.com> <53980F98.9090000@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Peter Crosthwaite Cc: Kevin Wolf , Paolo Bonzini , "qemu-devel@nongnu.org Developers" , Stefan Hajnoczi 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 allow >>> 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-unpl= ug >> Stefan and Kevin reported before I went on travels. >> >=20 > Welcome back. >=20 >> Any objection to moving this one line up into the if? >> >=20 > No problem. Will respin. I've done so myself, but now I wonder why we are checking obj->parent at all there after we already return if !obj->parent? Is this to guard against ObjectClass::unparent() changing Object::parent? Either way, the two variants you posted and I suggested should be fine. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg