[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

å 10/01/2014 11:32 PM, Ian Jackson åé:
scan-admin@xxxxxxxxxxxx writes ("New Defects reported by Coverity Scan for 
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

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
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 ?

Sure, I saw that Andrew has already post the patch, is there anything
else that I can do to help on this?



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.