[Xen-devel] Coverity complaints about Remus in xen-unstable

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

scan-admin@xxxxxxxxxxxx writes ("New Defects reported by Coverity Scan for 
XenProject"):
> Please find the latest report on new defect(s) introduced to XenProject found 
> with Coverity Scan.
...
> ** CID 1242320:  Uninitialized scalar variable  (UNINIT)
> /tools/libxl/libxl.c: 859 in libxl_domain_remus_start()

This is a failure to set rc on some of the error paths.  It is not a
big problem, but it is a bug which should be fixed, in
libxl_domain_remus_start.

Yang Hongyang, could you prepare a patch to fix all the error exit
paths from this function to correctly set rc ?  Thanks.


Then there are also a lot like this:

> ** CID 1242321:  Unused value  (UNUSED_VALUE)
> /tools/libxl/libxl_remus_device.c: 216 in all_devices_setup_cb()

These are all:

> >>>     Pointer "gc" returned by "libxl__ao_inprogress_gc(ao)" is never used.

This is because a lot of functions were introduced which say
    STATE_AO_GC(something)
but do not happen to use the gc.  This is actually perfectly normal
in libxl.  And the STATE_AO_GC macro says:
    libxl__gc *const gc __attribute__((unused)) = libxl__ao_inprogress_gc(ao)
So I think this is some kind of failure by Coverity.

Weirdly, although many of these uses (eg, all_devices_setup_cb at
libxl_remus_device.c:212) are in functions which do not use the
defined `ao' variable either, and ao is _not_ marked ok-to-be-unused,
Coverity hasn't complained about that.

Andrew Cooper, as our Coverity modelling expert, can you comment ?


I don't think there is actually anything wrong with having STATE_AO_GC
used when not needed.  It will reduce noise in future if code is added
which needs it, and in the meantime it's harmless.  So I think it
would probably be better if STATE_AO_GC declared ao
__attribute__((unused)) as well.

Yang Hongyang, supposing my comaintainers agree, would you care to
write a patch to do this ?


Thanks,
Ian.

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