|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 02/15] libxl: sanitize error handling in libxl_get_max_{cpus, nodes}
On Fri, 2013-11-22 at 19:56 +0100, Dario Faggioli wrote:
> @@ -4351,7 +4349,7 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx
> *ctx, int *nb_cpu_out)
> int max_cpus;
>
> max_cpus = libxl_get_max_cpus(ctx);
> - if (max_cpus == 0)
> + if (max_cpus <= 0)
Doesn't this slightly odd error condition (which includes 0 as an error)
actually stem from xc_get_max_cpus's broken handling of the case where
xc_physinfo failed?
It'd be better IMHO to make sure that this call chain ultimately returns
either a negative error or a positive number of cpus and never 0. I'd be
inclined to do that in xc_get_max_cpus. I suppose then
xc_get_{cpu,node}map_size would need error handling too. Handling it in
libxl_get_max_cpus might be reasonable too. That function really ought
to be returning libxl error codes, not -1 and errno as it currently
does.
If xc_physinfo is failing it seems unlikely that anything subsequent to
that is going to make much useful progress.
> @@ -4538,10 +4536,8 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx,
> uint32_t domid,
> }
>
> for (*nb_vcpu = 0; *nb_vcpu <= domaininfo.max_vcpu_id; ++*nb_vcpu,
> ++ptr) {
> - if (libxl_cpu_bitmap_alloc(ctx, &ptr->cpumap, 0)) {
> - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpumap");
> + if (libxl_cpu_bitmap_alloc(ctx, &ptr->cpumap, 0))
> return NULL;
Isn't this leaking ret == ptr here and everywhere else this returns?
> - }
> if (xc_vcpu_getinfo(ctx->xch, domid, *nb_vcpu, &vcpuinfo) == -1) {
> LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting vcpu info");
> return NULL;
> @@ -5304,7 +5300,7 @@ int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap
> *cpumap)
> int ncpus;
>
> ncpus = libxl_get_max_cpus(ctx);
> - if (ncpus == 0)
> + if (ncpus <= 0)
> return ERROR_FAIL;
If libxl_get_max_cpus returned a proper rc you could propagate it.
>
> cpumap->map = xc_cpupool_freeinfo(ctx->xch);
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 9f5f589..1815422 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -651,6 +651,56 @@ char *libxl_bitmap_to_hex_string(libxl_ctx *ctx, const
> libxl_bitmap *bitmap)
> return q;
> }
>
> +int libxl_cpu_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *cpumap, int
> max_cpus)
You seem to have combined code motion with actual changes here. Please
don't do that.
> +{
> + GC_INIT(ctx);
> + int rc = 0;
> +
> + if (max_cpus < 0) {
> + rc = ERROR_INVAL;
No need to log here?
> + goto out;
> + }
> + if (max_cpus == 0)
> + max_cpus = libxl_get_max_cpus(ctx);
> + if (max_cpus <= 0) {
> + LOG(ERROR, "failed to retrieve the maximum number of cpus");
> + rc = ERROR_FAIL;
> + goto out;
> + }
> + /* This can't fail: no need to check and log */
> + libxl_bitmap_alloc(ctx, cpumap, max_cpus);
> +
> + out:
> + GC_FREE;
> + return rc;
> +}
> +
> +int libxl_node_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *nodemap,
> + int max_nodes)
This is identical to cpu_bitmap alloc other than the parameter name and
the log message, isn't it? A common internal function, perhaps taking a
const char *what would eliminate that.
> +{
> + GC_INIT(ctx);
> + int rc = 0;
> +
> + if (max_nodes < 0) {
> + rc = ERROR_INVAL;
> + goto out;
> + }
> +
> + if (max_nodes == 0)
> + max_nodes = libxl_get_max_nodes(ctx);
> + if (max_nodes <= 0) {
> + LOG(ERROR, "failed to retrieve the maximum number of nodes");
> + rc = ERROR_FAIL;
> + goto out;
> + }
> + /* This can't fail: no need to check and log */
> + libxl_bitmap_alloc(ctx, nodemap, max_nodes);
> +
> + out:
> + GC_FREE;
> + return rc;
> +}
> +
> int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
> const libxl_bitmap *nodemap,
> libxl_bitmap *cpumap)
> @@ -719,12 +769,16 @@ int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
>
> int libxl_get_max_cpus(libxl_ctx *ctx)
> {
> - return xc_get_max_cpus(ctx->xch);
> + int max_cpus = xc_get_max_cpus(ctx->xch);
> +
> + return max_cpus <= 0 ? ERROR_FAIL : max_cpus;
Aha, so there is indeed no need for all the <= changes in the callers.
Good!
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |