Re: [PATCH v3 10/10] libxl: fix caller of libxl_cpupool functions

[Wei Liu <wei.liu2@citrix.com>]

On Tue, Jul 14, 2015 at 06:33:22PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v3 10/10] libxl: fix caller of libxl_cpupool functions"):
> > Coverity complains cpupool_info leaks a string in failure path. Instead
> > of fixing that path, we rely on the callers (two public APIs at the
> > moment) of cpupool_info correctly call libxl_cpupoolinfo_dispose in
> > their failure path to dispose of any resources.
> 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index 38aff8d..02b4a26 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -771,8 +771,11 @@ libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool_out)
> >  
> >      poolid = 0;
> >      for (i = 0;; i++) {
> > -        if (cpupool_info(gc, &info, poolid, false))
> > +        libxl_cpupoolinfo_init(&info);
> > +        if (cpupool_info(gc, &info, poolid, false)) {
> > +            libxl_cpupoolinfo_dispose(&info);
> >              break;
> > +        }
> 
> I'm not convinced by this change.
> 
> I think that this function has broken error handling: if cpupool_info
> fails, it simply ignores the error.
> 

I think the semantics of this function is to get back as many cpupool
info as it can.

Unfortunately the failing of cpupool_info can either mean the cpupool id
does not exist or other internal errors.  So not cleaning up is the
right thing to do (speaking from semantics point of view).

I think I need to overhaul cpupool_info a bit if we want to make this
API better.

I'm not sure if it is possible to interleave pool ids. If so, we need a
way to get back the exact number of cpupools. Dario?

Wei.

> To fix this, it would have to clean up the array properly.
> 
> Furthermore, I don't understand why it uses the temporary variable
> `info'.  Surely it could have cpupool_info write directly into the
> right array slot.  If it did that, then the error handling path would
> work to free up any failure.
> 
> 
> By putting both these fixes in the same patch, you have denied me the
> opportunity to ack the other change, which is fine ...
> 
> Ian.