On 18/05/15 15:34, Boris Ostrovsky wrote: > On 05/18/2015 10:09 AM, Andrew Cooper wrote: >> 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. > > Ah, OK. xc_cputopoinf() (or, rather, the hypervisor) actually doesn't > use the value of dereferenced num_cpus in this case but obviously > Coverity can't know about this. > > So Coverity cross-checks routines to see how callers use the arguments?
xc_cputopoinfo(ctx->xch, &num_cpus, NULL) dereferences &num_cpus as part of its DECLARE_HYPERCALL_BUFFER()s. All of this happens before getting anywhere near the hypervisor. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
