From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: sanitizing kvmtool Date: Mon, 19 Oct 2015 10:19:32 -0400 Message-ID: <5624FBF4.20201@oracle.com> References: <5622583D.2060006@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Sasha Levin , Pekka Enberg , Asias He , penberg@cs.helsinki.fi, Cyrill Gorcunov , Will Deacon , andre.przywara@arm.com, matt@ozlabs.org, laijs@cn.fujitsu.com, Michael Ellerman , Prasad Joshi , marc.zyngier@arm.com, "Aneesh Kumar K.V" , mingo@elte.hu, gorcunov@openvz.org, andreas.herrmann@caviumnetworks.com, kvm@vger.kernel.org, Kostya Serebryany , Evgenii Stepanov , Alexey Samsonov , Alexander Potapenko To: Dmitry Vyukov Return-path: Received: from aserp1040.oracle.com ([141.146.126.69]:21864 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751386AbbJSOU2 (ORCPT ); Mon, 19 Oct 2015 10:20:28 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 10/19/2015 04:37 AM, Dmitry Vyukov wrote: >> So in this case (and most of the other data race cases described in the full log) it >> > seems like ThreadSanitizer is mixing with different accesses by the guest to one underlying >> > block of memory on the host. >> > >> > Here, for example, T55 accesses the msix block of the virtio-net PCI device, and T58 is accessing >> > the virtqueue exposed by that device. While they both get to the same block of memory inside > I don't understand this. > Do you mean that this is a false positive? Or it is a real issue in lkvm? I suspect it's a false positive because ThreadSanitizer sees the memory as one big block, but the logic that makes sure we don't race here is within the guest vm, which ThreadSanitizer doesn't see. Thanks, Sasha