[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] spapr: fix write-past-end-of-array error in cpu
From: |
Bharata B Rao |
Subject: |
Re: [Qemu-devel] [PATCH] spapr: fix write-past-end-of-array error in cpu core device init code |
Date: |
Tue, 28 Jun 2016 13:30:47 +0530 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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 <address@hidden> 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 <address@hidden>
> > > > ---
> > > > 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.