From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy1qL-00039A-Tu for qemu-devel@nongnu.org; Tue, 31 Dec 2013 11:07:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vy1qF-0007rI-UV for qemu-devel@nongnu.org; Tue, 31 Dec 2013 11:06:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy1qF-0007o1-Mm for qemu-devel@nongnu.org; Tue, 31 Dec 2013 11:06:51 -0500 Message-ID: <52C2EB94.4050906@redhat.com> Date: Tue, 31 Dec 2013 17:06:44 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1388477217-23491-1-git-send-email-akong@redhat.com> In-Reply-To: <1388477217-23491-1-git-send-email-akong@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qdev: unparent device when fails to set properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amos Kong Cc: qemu-devel@nongnu.org, aliguori@amazon.com, afaerber@suse.de Il 31/12/2013 09:06, Amos Kong ha scritto: > When it fails to set properties, qdev's parent is already set Do not confuse the QOM parent (which is /machine/peripheral, of which the new device is a child) with the qdev parent bus (which has a link to the new device)! In general, you should add the device to the QOM tree before using it to set a link. So I believe that object_property_add_child should be called before qdev_set_parent_bus. This is the root cause of the bug; the fix then could be one of the following: 1) move qdev_set_parent_bus later; 2) move object_property_add_child before the setting of properties. I slightly prefer the first, so that initialization happens in this order: 1) create object 2) set properties -- if it fails, you can just unref the object 3) add child -- if it fails due to duplicate ID, you can again just unref the object 4) set parent bus (cannot fail) 5) realize -- if it fails, you need to unparent the object and unref the object 6) drop the reference now that the object is kept solidly alive by QOM/qdev, and return. This matches a bit more closely what happens with object-add, too. Paolo