Re: [Xen-devel] [PATCH] libxl: fix an error path that uses uninitialised rc in libxl_set_memory_target

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jun 22, 2016 at 09:20:57AM -0600, Jan Beulich wrote:
> >>> On 22.06.16 at 15:59, <wei.liu2@xxxxxxxxxx> wrote:
> > On Wed, Jun 22, 2016 at 07:53:56AM -0600, Jan Beulich wrote:
> >> >>> On 22.06.16 at 15:47, <wei.liu2@xxxxxxxxxx> wrote:
> >> > On Wed, Jun 22, 2016 at 06:58:28AM -0600, Jan Beulich wrote:
> >> >> >>> On 12.06.16 at 16:09, <wei.liu2@xxxxxxxxxx> wrote:
> >> >> > --- a/tools/libxl/libxl.c
> >> >> > +++ b/tools/libxl/libxl.c
> >> >> > @@ -4927,10 +4927,12 @@ retry_transaction:
> >> >> >  
> >> >> >      target = libxl__xs_read(gc, t, GCSPRINTF("%s/memory/target", 
> > dompath));
> >> >> >      if (!target && !domid) {
> >> >> > -        if (!xs_transaction_end(ctx->xsh, t, 1))
> >> >> > +        if (!xs_transaction_end(ctx->xsh, t, 1)) {
> >> >> > +            rc = ERROR_FAIL;
> >> >> 
> >> >> I'm sorry for noticing this only now - is ERROR_FAIL the right thing
> >> >> to use here, considering how things worked before the change that
> >> >> introduced the issue getting fixed here? I had intentionally decided
> >> >> to use ERROR_INVAL in the patch variant I did submit (as at that
> >> >> time I wasn't yet aware of the other fix floating around already).
> >> >> 
> >> > 
> >> > When I wrote this patch, I thought the return value should be tied to
> >> > xs_transaction_end.
> >> 
> >> xs_transaction_end() returning zero means success afaict.
> >> 
> > 
> > /* End a transaction.
> >  * If abandon is true, transaction is discarded instead of committed.
> >  * Returns false on failure: if errno == EAGAIN, you have to restart
> >  * transaction.
> >  */
> > bool xs_transaction_end(struct xs_handle *h, xs_transaction_t t,
> >                         bool abort);
> > 
> > I think you misread.
> 
> Indeed, I got mislead by "goto out_no_transaction". Yet that
> doesn't change the discussion of the error - originally this didn't
> return -1 here, but +1 (i.e. reflecting the surrounding if(), not
> the inner one).
> 

So that comes back to the intent of ecdc6fd8 -- to fix the mad semantics
of that function. We don't need to duplicate what it did before.

Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel