[Qemu-devel] Coverity scan successes

[Qemu-devel] Coverity scan successes

[Paolo Bonzini]

Hi all,

I'm happy to announce that the number of outstanding Coverity-reported 
defects in QEMU is now down to 0.33 per 1000 lines of code.  This is 
half the average defect density for open source project (0.69) and also 
lower than the average defect density for projects in the 500k-1M SLOC 
range (0.44).

3 months ago the ratio was 0.88.  Since then it has gone down steadily 
thanks to the effort of those who triaged the Coverity reports 
(including a couple of people who as far as I know have no other 
relationship with the community, and Peter who also reviewed other 
people's findings), and those who fixed the bugs (again Peter, and Markus).

Of course, the defect density varies across subsystems:

					ratio		# defects
	SLIRP				2.86		20
	9pfs/virtio-9p			1.69		16
	Bluetooth			1.31		6
	NBD				1.31		2
	User-mode emulation		0.84		25
	Block layer			0.66		25
	Migration			0.61		2
	PCI				0.54		6
	SCSI				0.59		8
	Networking			0.48		11
	ARM device models		0.34		13		
	USB				0.24		5
	(Anything else)			0.23		149
	TCG				0.09		1
	Monitor				0.08		2
	Tracing				0.00		0

Of course these data have to be taken with a grain of salt, as subsystem 
boundaries are not necessarily sharp, but I think that the overall 
picture is pretty good.  Of the 4 top "offenders", three actually match 
little-used (and unfortunately also little-maintained) functionality. 
And there are several subsystems that could easily go down to zero defects.

You may have noticed that I've sent a couple of nag mails to people who 
had their code flagged by Coverity.  Because of the nature of QEMU, 
sometimes people simply cannot know what you intended to do without 
accurate documentation or datasheets for the hardware you're emulating. 
  What may look like a simple off-by-one error might actually hide an 
incorrect interpretation of the datasheet.  For this reason, it is 
important for authors of the code to fix things when they are reported 
to them.

There is of course still work to do.  There are 100 actual bugs still to 
be fixed, most of them insignificant or minor but also some memory 
corruptions; almost 200 issues are still pending triage.

Another interesting thing to do is to write models 
(https://scan.coverity.com/models) for functions that Coverity 
consistently reports false positives about.  address_space_rw is a 
particularly central one.

If you are interested in helping out, you can contact me offlist.

Paolo

Re: [Qemu-devel] Coverity scan successes

[Kevin Wolf]

Hi Paolo,

Am 14.03.2014 um 13:20 hat Paolo Bonzini geschrieben:
> Of course, the defect density varies across subsystems:
> 
> 					ratio		# defects
> 	SLIRP				2.86		20
> 	9pfs/virtio-9p			1.69		16
> 	Bluetooth			1.31		6
> 	NBD				1.31		2
> 	User-mode emulation		0.84		25
> 	Block layer			0.66		25

How would I get access to the Coverity results? I feel the block layer
is scoring a bit too high here... :-)

Kevin

Re: [Qemu-devel] Coverity scan successes

[Paolo Bonzini]

Il 17/03/2014 10:31, Kevin Wolf ha scritto:
>
> Am 14.03.2014 um 13:20 hat Paolo Bonzini geschrieben:
>> > Of course, the defect density varies across subsystems:
>> >
>> > 					ratio		# defects
>> > 	SLIRP				2.86		20
>> > 	9pfs/virtio-9p			1.69		16
>> > 	Bluetooth			1.31		6
>> > 	NBD				1.31		2
>> > 	User-mode emulation		0.84		25
>> > 	Block layer			0.66		25
> How would I get access to the Coverity results?

You ask. :)

> I feel the block layer
> is scoring a bit too high here... :-)

Well, five of those are simply new unchecked uses of strstart that 
Coverity complains about and I've muted them so you're already down to 
0.5. :)

Most of the problems are overflows caused by int32 multiplications (such 
as number of sectors * 512, or number of clusters * clusters per sector) 
before casting to int64.  Many of them probably cannot really happen, 
because one of the factor is small and related to the size of an L2 
table; for example the number of sectors could be the size of an L2 
table, or the number of clusters could be the number of entries in an L2 
table.

Paolo