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


Re: [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__creat

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__create_stubdom
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Wed, 22 Jun 2011 18:59:19 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Wei Liu <liuw@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 22 Jun 2011 10:55:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19968.43454.234108.5386@xxxxxxxxxxxxxxxxxxxxxxxx>
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: <1307595829.8990.9.camel@limbo> <1307606121.775.761.camel@xxxxxxxxxxxxxxxxxxxxxx> <1307608287.31235.17.camel@limbo> <1307615031.775.810.camel@xxxxxxxxxxxxxxxxxxxxxx> <19963.37638.19033.472036@xxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1106202003430.12963@kaball-desktop> <19968.36303.693667.57932@xxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1106211458460.12963@kaball-desktop> <19968.43454.234108.5386@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Tue, 21 Jun 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] Re: [PATCH] libxl: initialize 
> domid to 0 in libxl__create_stubdom"):
> > I understand what you mean, but in that case I would rather have the
> > check right before allocate:
> > 
> > assert(!libxl_domid_valid_guest(*domid));
> > something = allocate();
> >
> > in the outer function.
> What?  Are you proposing this:
>     char *something = NULL;
>     uint32_t domid = -1;
>     ...
>     assert(!libxl_domid_valid_guest(*domid));
>     assert(!something);
>     ...
>     something = allocate();
>     if (!something) goto error_exit;
>     ...
>     ret = libxl__domain_make(&domid);
>     if (ret) goto error_exit;
>     ...
>     return successfully somehow;
>    error_exit:
>     free(something);
>     if (libxl_domid_valid_guest(domid))
>         libxl_domain_destroy(domid);
> What would be the point of that ?
For clarity I'll keep calling this function the "outer" function even
though there are no inner functions in this example.

The problem you are talking about is forgetting to initialize domid in
the outer function then jumping to error_exit because of an error in
allocate(), as a consequence libxl_domid_valid_guest is called passing
an UNDEFINED argument. Am I right?

This problem is caused by the way the outer function is coded and should not
affect the way other functions are coded.
I don't think that editing other independent functions is a good way of
making the outer function more resilient.

The specific problem you mentioned can be solved by simply initializing
domid in the outer function.
If you would like a double check you can introduce an assert in the
outer function; libxl__domain_make is not the right place for it.

Xen-devel mailing list