On Tue, Jun 28, 2016 at 04:24:22PM +1000, David Gibson wrote: > On Tue, Jun 28, 2016 at 07:24:16AM +0200, Greg Kurz wrote: > > On Tue, 28 Jun 2016 12:55:07 +1000 > > David Gibson <da...@gibson.dropbear.id.au> wrote: > > > > > On Mon, Jun 27, 2016 at 06:28:15PM +0200, Greg Kurz wrote: > > > > This fixes a potential QEMU crash introduced by commit 3b542549661. > > > > > > > > Signed-off-by: Greg Kurz <gr...@kaod.org> > > > > --- > > > > hw/ppc/spapr_cpu_core.c | 3 +-- > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > Ugh. The existing code is wrong in the case where the failure happens > > > after the loop. > > > > > > But this version is wrong in the case it happens during the loop - it > > > will fail to clean up the last object created. > > > > > > > Hmm... unless I'm missing something, if object_property_add_child() fails to > > add object i, we don't want to unparent it, and we should start rollback > > at index i-1. > > Good point, my mistake. I'll apply this fix. > > > > > Another weirdness is that I see no rollback for the object_child_foreach() > > loop: in case of failure, we will unparent realized objects... is it > > okay ? > > Um.. I have no idea. Bharata? Alex?
This is similar to how device_add code recovers when there is failure during realize. So I think object_unparent() should be fine. Only other thing I need to verify is whether an additional object_unref() is needed after unparenting. Regards, Bharata.
