On 18/05/15 15:00, Boris Ostrovsky wrote: > On 05/18/2015 08:57 AM, Andrew Cooper wrote: >> These changesets cause the respective libxc functions to unconditonally >> dereference their max_cpus/nodes parameters as part of initial memory >> allocations. It will fail at obtaining the correct number of >> cpus/nodes from >> Xen, as the guest handles will not be NULL. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >> CC: Ian Campbell <ian.campb...@citrix.com> >> CC: Ian Jackson <ian.jack...@eu.citrix.com> >> CC: Wei Liu <wei.l...@citrix.com> >> CC: Boris Ostrovsky <boris.ostrov...@oracle.com> >> >> --- >> Spotted by XenServers Coverity run. >> --- >> tools/libxl/libxl.c | 4 ++-- >> tools/misc/xenpm.c | 4 ++-- >> tools/python/xen/lowlevel/xc/xc.c | 4 ++-- >> 3 files changed, 6 insertions(+), 6 deletions(-) > > xenpm bug is already fixed (commit > b315cd9cce5b6da7ca89b2d7bad3fb01e7716044 n the staging tree). > > I am not sure I understand why Coverity complains about other spots. > For example, in libxl_get_cpu_topology() num_cpus can be left > uninitialized only if xc_cputopoinfo(ctx->xch, &num_cpus, NULL) fails, > in which case we go to 'GC_FREE; return ret;', so it's not ever used.
xc_cputopoinfo(ctx->xch, &num_cpus, NULL) unconditionally dereferences and reads &num_cpus, and performs a memory allocation based on the result. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
