From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkEQC-00062U-NO for qemu-devel@nongnu.org; Fri, 31 Oct 2014 11:48:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xjpe9-00085U-F4 for qemu-devel@nongnu.org; Thu, 30 Oct 2014 09:20:22 -0400 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:41239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjpe9-00085N-63 for qemu-devel@nongnu.org; Thu, 30 Oct 2014 09:20:13 -0400 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 30 Oct 2014 13:20:11 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3002E1B0805F for ; Thu, 30 Oct 2014 13:20:14 +0000 (GMT) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s9UDKAIZ15794508 for ; Thu, 30 Oct 2014 13:20:10 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s9U8Hgav010544 for ; Thu, 30 Oct 2014 04:17:42 -0400 Message-ID: <54523B09.7000108@de.ibm.com> Date: Thu, 30 Oct 2014 14:20:09 +0100 From: Christian Borntraeger MIME-Version: 1.0 References: <1414661809-21383-1-git-send-email-borntraeger@de.ibm.com> <5452370E.90407@redhat.com> In-Reply-To: <5452370E.90407@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/9] valgrind/i386/s390x: memcheck false positives List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Peter Maydell Cc: qemu-devel Am 30.10.2014 14:03, schrieb Paolo Bonzini: > On 10/30/2014 10:36 AM, Christian Borntraeger wrote: >> Some of these things could >> also be fixed in valgrind, but it will take a while until these changes >> hit a release or distros. > > Ok, it's sensible to have it fixed in QEMU if it's temporary. Which > could not be fixed in valgrind? This is a tricky question. A typical annotation in valgrind for an more complex ioctl looks like case VKI_SIOCGMIIREG: /* get hardware entry registers */ PRE_MEM_RASCIIZ( "ioctl(SIOCGIFMIIREG)", (Addr)((struct vki_ifreq *)ARG3)->vki_ifr_name ); PRE_MEM_READ( "ioctl(SIOCGIFMIIREG)", (Addr)&((struct vki_mii_ioctl_data *)&((struct vki_ifreq *)ARG3)->vki_ifr_data)->phy_id, sizeof(((struct vki_mii_ioctl_data *)&((struct vki_ifreq *)ARG3)->vki_ifr_data)->phy_id) ); PRE_MEM_READ( "ioctl(SIOCGIFMIIREG)", (Addr)&((struct vki_mii_ioctl_data *)&((struct vki_ifreq *)ARG3)->vki_ifr_data)->reg_num, sizeof(((struct vki_mii_ioctl_data *)&((struct vki_ifreq *)ARG3)->vki_ifr_data)->reg_num) ); PRE_MEM_WRITE( "ioctl(SIOCGIFMIIREG)", ARG3, sizeof(struct vki_ifreq)); break; This scheme works fine as long as the ioctl is unchanged. So any ioctl that has padding and no flags this should be doable. For all KVM ioctls with reserved fields that might become used on certain flags, we have two options: a: we would instruct valgrind to not check the reserved fields Whenever we start using them, we would still not check those field b: we would instruct valgrind to not check the reserved fields if flags has a certain value (e.g. 0), otherwise all reserved fields would be checked. Whenever we start using the reserved fields, valgrind would complain unless we write all. So in that case we have to modify valgrind again In essence a will cause false negatives, b will cause false positives I think b is preferred Christian