From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOR6X-0001mf-5f for qemu-devel@nongnu.org; Fri, 14 Mar 2014 08:20:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOR6Q-0005kk-St for qemu-devel@nongnu.org; Fri, 14 Mar 2014 08:20:49 -0400 Received: from mail-ee0-x235.google.com ([2a00:1450:4013:c00::235]:37386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOR6Q-0005kT-LR for qemu-devel@nongnu.org; Fri, 14 Mar 2014 08:20:42 -0400 Received: by mail-ee0-f53.google.com with SMTP id b57so667370eek.12 for ; Fri, 14 Mar 2014 05:20:41 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5322F415.4070409@redhat.com> Date: Fri, 14 Mar 2014 13:20:37 +0100 From: Paolo Bonzini MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Coverity scan successes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel , mattjd@gmail.com, Mark Cave-Ayland 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