Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2219502ybe; Sat, 7 Sep 2019 11:08:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqweuzg3fluu3K2AW6DIpD2BaaaJcwVCkS2b2B0d4sl9wfhD8xAqbiKxRqTAno3CQRVO4YBe X-Received: by 2002:a17:90a:3387:: with SMTP id n7mr15848128pjb.26.1567879704622; Sat, 07 Sep 2019 11:08:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567879704; cv=none; d=google.com; s=arc-20160816; b=lBVViqt2bFYpbbTQT4iC3SUxnTvzMGfmCUa0ebx19YOCxYUkF4JIzJw1v1TZdHbRmc Cj1bScXp/DmfWQcfnAj9q/Am7Lb1XW6Th7TOnU4WHo/waZdr9MDmuLsfL6A/zOGilDJl ifvQsTuMMrZQre5Ok0ZTdzPn0yJmMIS9WsoYFMwuOUHSIbFCe+RRCOFiwger9rE5MtWG ADARvbJKREMS020M0ix2RsP76jrS966NCiw70XUSlgU+bnZ1UWYEHe3ZfiQSjWy86PIe 320lRBwknkIp2MU3kSAZ6zH3eqJcK8AZ5u313aeOqnUU00c/WTHzcW0rvH53CFHrGu2v 0nMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:subject:cc:to :from:date; bh=jOLHpY7MkFcsrB1Zp6BsfLn890KfliVgJC0SHp7i8Ak=; b=quZOCv851d8hLuhtF0Uq7X6UcwWM4EesfRrZ7ooz+4zRJfG2Wx2jhxSV07Vk37NFki hRIprewSUFXZB1HfmKWc0DRgMcTxj4dV2XwRuZJZtYP+1MANfCMrTzzRVi7U5GEttIAo LqmdVVRnSnZB2oK7stIE7TH0PVx3UH2+yLsBuvlJSDzkLOkORrybT6oS1Rz98TMy1AAw FM7n9RhgN80OqG/ir4spPmC+sS3WETihfyaSGMveKap3wUTugq5p5LJOUqIRFYxLyS8W gpTrPWk9MAbhUmefviQAHFI7mQyI+MPCJoZEfXFT2n+PgRwz9VjIjxWwP555DAHicpmL /GTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si8083268pld.255.2019.09.07.11.08.09; Sat, 07 Sep 2019 11:08:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391255AbfIFU5X (ORCPT + 99 others); Fri, 6 Sep 2019 16:57:23 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:41592 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2387949AbfIFU5X (ORCPT ); Fri, 6 Sep 2019 16:57:23 -0400 Received: (qmail 6367 invoked by uid 2102); 6 Sep 2019 16:57:22 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Sep 2019 16:57:22 -0400 Date: Fri, 6 Sep 2019 16:57:22 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: LKMM Maintainers -- Akira Yokosawa , Andrea Parri , Boqun Feng , Daniel Lustig , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Will Deacon cc: Kernel development list Subject: [PATCH RFC] tools/memory-model: Fix data race detection for unordered store and load Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently the Linux Kernel Memory Model gives an incorrect response for the following litmus test: C plain-WWC {} P0(int *x) { WRITE_ONCE(*x, 2); } P1(int *x, int *y) { int r1; int r2; int r3; r1 = READ_ONCE(*x); if (r1 == 2) { smp_rmb(); r2 = *x; } smp_rmb(); r3 = READ_ONCE(*x); WRITE_ONCE(*y, r3 - 1); } P2(int *x, int *y) { int r4; r4 = READ_ONCE(*y); if (r4 > 0) WRITE_ONCE(*x, 1); } exists (x=2 /\ 1:r2=2 /\ 2:r4=1) The memory model says that the plain read of *x in P1 races with the WRITE_ONCE(*x) in P2. The problem is that we have a write W and a read R related by neither fre or rfe, but rather W ->coe W' ->rfe R, where W' is an intermediate write (the WRITE_ONCE() in P0). In this situation there is no particular ordering between W and R, so either a wr-vis link from W to R or an rw-xbstar link from R to W would prove that the accesses aren't concurrent. But the LKMM only looks for a wr-vis link, which is equivalent to assuming that W must execute before R. This is not necessarily true on non-multicopy-atomic systems, as the WWC pattern demonstrates. This patch changes the LKMM to accept either a wr-vis or a reverse rw-xbstar link as a proof of non-concurrency. Signed-off-by: Alan Stern --- tools/memory-model/linux-kernel.cat | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: usb-devel/tools/memory-model/linux-kernel.cat =================================================================== --- usb-devel.orig/tools/memory-model/linux-kernel.cat +++ usb-devel/tools/memory-model/linux-kernel.cat @@ -197,7 +197,7 @@ empty (wr-incoh | rw-incoh | ww-incoh) a (* Actual races *) let ww-nonrace = ww-vis & ((Marked * W) | rw-xbstar) & ((W * Marked) | wr-vis) let ww-race = (pre-race & co) \ ww-nonrace -let wr-race = (pre-race & (co? ; rf)) \ wr-vis +let wr-race = (pre-race & (co? ; rf)) \ wr-vis \ rw-xbstar^-1 let rw-race = (pre-race & fr) \ rw-xbstar flag ~empty (ww-race | wr-race | rw-race) as data-race