| Message ID | 146704489509.8607.12236848738501803903.stgit@bahia.lan (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <groug@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. > diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c > index 3a5da09b9902..8b802a6fcf0b 100644 > --- a/hw/ppc/spapr_cpu_core.c > +++ b/hw/ppc/spapr_cpu_core.c > @@ -309,10 +309,9 @@ static void spapr_cpu_core_realize(DeviceState *dev, Error **errp) > } > > err: > - while (i >= 0) { > + while (--i >= 0) { > obj = sc->threads + i * size; > object_unparent(obj); > - i--; > } > g_free(sc->threads); > error_propagate(errp, local_err); >
On Tue, 28 Jun 2016 12:55:07 +1000 David Gibson <david@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 <groug@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. 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 ? > > diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c > > index 3a5da09b9902..8b802a6fcf0b 100644 > > --- a/hw/ppc/spapr_cpu_core.c > > +++ b/hw/ppc/spapr_cpu_core.c > > @@ -309,10 +309,9 @@ static void spapr_cpu_core_realize(DeviceState *dev, Error **errp) > > } > > > > err: > > - while (i >= 0) { > > + while (--i >= 0) { > > obj = sc->threads + i * size; > > object_unparent(obj); > > - i--; > > } > > g_free(sc->threads); > > error_propagate(errp, local_err); > > >
On Tue, Jun 28, 2016 at 07:24:16AM +0200, Greg Kurz wrote: > On Tue, 28 Jun 2016 12:55:07 +1000 > David Gibson <david@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 <groug@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? > > > > diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c > > > index 3a5da09b9902..8b802a6fcf0b 100644 > > > --- a/hw/ppc/spapr_cpu_core.c > > > +++ b/hw/ppc/spapr_cpu_core.c > > > @@ -309,10 +309,9 @@ static void spapr_cpu_core_realize(DeviceState *dev, Error **errp) > > > } > > > > > > err: > > > - while (i >= 0) { > > > + while (--i >= 0) { > > > obj = sc->threads + i * size; > > > object_unparent(obj); > > > - i--; > > > } > > > g_free(sc->threads); > > > error_propagate(errp, local_err); > > > > > >
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 <david@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 <groug@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.
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c index 3a5da09b9902..8b802a6fcf0b 100644 --- a/hw/ppc/spapr_cpu_core.c +++ b/hw/ppc/spapr_cpu_core.c @@ -309,10 +309,9 @@ static void spapr_cpu_core_realize(DeviceState *dev, Error **errp) } err: - while (i >= 0) { + while (--i >= 0) { obj = sc->threads + i * size; object_unparent(obj); - i--; } g_free(sc->threads); error_propagate(errp, local_err);
This fixes a potential QEMU crash introduced by commit 3b542549661. Signed-off-by: Greg Kurz <groug@kaod.org> --- hw/ppc/spapr_cpu_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)