This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [Qemu-devel] [PATCH v2] xen_disk: cope with missing xens

To: Peter Maydell <peter.maydell@xxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH v2] xen_disk: cope with missing xenstore "params" node
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 27 Jun 2011 14:40:24 +0100
Cc: "agraf@xxxxxxx" <agraf@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 27 Jun 2011 06:37:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTimjqgtTZDfWSJAO2NXPMZ8S0kA82g@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1308933348-12022-1-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <BANLkTimjqgtTZDfWSJAO2NXPMZ8S0kA82g@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Sat, 25 Jun 2011, Peter Maydell wrote:
> On 24 June 2011 17:35,  <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > +out_error:
> > +    qemu_free(blkdev->params);
> > +    qemu_free(blkdev->mode);
> > +    qemu_free(blkdev->type);
> > +    qemu_free(blkdev->dev);
> > +    qemu_free(blkdev->devtype);
> > +    return -1;
> It occured to me that could result in a double-free if it's
> possible to call init again (or to call free) after the init
> routine has returned failure. I don't know enough about the
> Xen device lifecycle to know if that's possible, though -- is it?

It shouldn't happen, but xen_disk should be able to cope with it
I am going to resend the patch again setting to NULL all the blkdev
fields after freeing them.
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>