From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bm2xc-0007vr-2E for qemu-devel@nongnu.org; Mon, 19 Sep 2016 14:06:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bm2xX-0007vK-TI for qemu-devel@nongnu.org; Mon, 19 Sep 2016 14:06:30 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:45969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bm2xV-0007eg-KC for qemu-devel@nongnu.org; Mon, 19 Sep 2016 14:06:27 -0400 Date: Mon, 19 Sep 2016 14:06:14 -0400 From: "Emilio G. Cota" Message-ID: <20160919180614.GA8713@flamenco> References: <20160919155139.28371-1-alex.bennee@linaro.org> <20160919155139.28371-8-alex.bennee@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160919155139.28371-8-alex.bennee@linaro.org> Subject: Re: [Qemu-devel] [RFC 7/8] util/qht: atomically set b->hashes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex =?iso-8859-1?Q?Benn=E9e?= Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, stefanha@redhat.com, kwolf@redhat.com, mttcg@listserver.greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, bobby.prani@gmail.com, nikunj@linux.vnet.ibm.com, mark.burton@greensocs.com, jan.kiszka@siemens.com, serge.fdrv@gmail.com, rth@twiddle.net, peter.maydell@linaro.org, claudio.fontana@huawei.com On Mon, Sep 19, 2016 at 16:51:38 +0100, Alex Bennée wrote: > ThreadSanitizer detects a possible race between reading/writing the > hashes. As ordering semantics are already documented for qht we just > need to ensure a race can't tear the hash value so we can use the > relaxed atomic_set/read functions. This was discussed here: https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg03658.html To reiterate: reading torn hash values is fine, since the retry will happen regardless (and all pointers[] remain valid through the RCU read-critical section). Couldn't we just tell tsan to ignore it? Thanks, Emilio