Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5218016ybe; Tue, 17 Sep 2019 04:44:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqzS24MlXYrZ+vnU7tnrbz/eOMPg04u6DVomXX2LsgYzK1Opc2IQICY5179IDT5LTTpQRVus X-Received: by 2002:a17:906:b211:: with SMTP id p17mr4244854ejz.11.1568720682640; Tue, 17 Sep 2019 04:44:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568720682; cv=none; d=google.com; s=arc-20160816; b=rfZMTaF567Hma06Slql1eeLKAPgpjGkt1TXeB+u+HMeCkK6KawdyWTftn09/idRcaR 9rh2qI55ZZucGsbqSKB3ImdS+uZmOuLiGXICrAT/zgHP+BKWCSUDrgY1Fys8+kpxFL+W um/y1aHUmfWgAy0l6r7pIzqZPGO3Q3Do3DzFZ5dCanPsc5f1oZZZtIdzs80Hp0sVcDmO D5ziMyHLQNWxepLdw5DJp4KNUJankymWxgZmHMiTjsB2AmoHeNdOQa6tGTmL6dHaXaIv 9Z0fo16fF0FIb+wsm4Vd6uoQ18n0Z7iwEE2FzntUkPMiyJu08wwYrbNFSYlxAsCVA5rn hSmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=rx9AKEs9on8tyYzLlreqCPVJ+4zzfyMgS08lHc287dE=; b=pw88KtHELqBqmSw/akNQQDRYGNLY5klpt2Q8vOMHZQH5PlXYPCXFhsiXOy0odjmvEB dhQyvmG6U3ZbttHTylwqEL3+B6oKSn+rC3VXaT0kmn9wuN8z8siJZd3WbvOL2Z1e9zj/ h3XZHjtKShp32akWGFu/UJjTxZ4tYygztvzMTVNPxkSBcogmVXUcDiCa5DNv1VvYj2/r e4CrPGIH1QVWjv7FKYpM8Wu2OMvvdegRuiyiFjS+02Pq598X1VYdLLxb4lxBYYujlIZa HsOIJsYP4BOQZ4IJMOsc0Cw01MltCfqf6iuMRW6OdfqZkHUMPInhvPbLmK05XA3aYa5A qpew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=X8DBZDe8; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u23si942325ejr.204.2019.09.17.04.44.19; Tue, 17 Sep 2019 04:44:42 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=X8DBZDe8; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726820AbfIQLkK (ORCPT + 99 others); Tue, 17 Sep 2019 07:40:10 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:39384 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726207AbfIQLkK (ORCPT ); Tue, 17 Sep 2019 07:40:10 -0400 Received: by mail-wm1-f66.google.com with SMTP id v17so2749971wml.4 for ; Tue, 17 Sep 2019 04:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rx9AKEs9on8tyYzLlreqCPVJ+4zzfyMgS08lHc287dE=; b=X8DBZDe8Px1+h0H6RVpyDi5jzbWbwe+4f8Gsxb3EgsBCHps85/an1xxesJJy9F/jvw Y6E2IMjMt/HU3hLmUpXgdIfA5fURzFgRzaVJGX1LK9G5At5QCR5zi12CgOfTNCNexS2x lV/ZvOf+pEPrLRj+MUpL158CJ7UKtvNSjPkSW06F+zKZFN/51JOJBtE2eVxjcL7j5U0s qDK7h+l30DNCPOXVN8dCTfLdMSocMCYn3Sap3G/HnyjqWH6dysHIl5xKLRfHhQGK3kUL KraUwobZ8qM2Qlo9SUGBOkdlpBF8cOT3IIQyWtp5PTTG7W/GCwepR2pH2pBE4OJEpjqD ndlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rx9AKEs9on8tyYzLlreqCPVJ+4zzfyMgS08lHc287dE=; b=kZ0lApOhh1efFbml2vW+yOiNOoGY6iQwkP+Go0Yp/LWd82keo0y8FvFxiwQDw5+MUZ GM+ZTAOdTgi3Q+5yU5f4lcxcZCNF3IyoB4qwzwV6fkxCyb+WdMPraOhcNE9ADjbGqe/7 KUyrIArnP01PhxfK0f5JjItaQZrCimX39PYKgnmSoLFqcvUhs42Jr8WUJvsWFUiwbZ/y grU8D/LgFZkac9pHMn7Ho8RcRZTn8itziFfPgxzociEu5FL7Ov+VgtHd2yE5CR1ryFJd G+xIwfoPikrJxWsePFTjpgWOwLWZFv8/FBP/6U0WLXfQOSbx1Hucbdn1zKmhznkDqqJT PWCQ== X-Gm-Message-State: APjAAAXAxNymSFVq4l09d5vWowZBnBj42Q1hO9uOZSAWMtQSVZiH3cgy wy7kruWGOocf4LeCbB/FYdE= X-Received: by 2002:a05:600c:34e:: with SMTP id u14mr2936855wmd.110.1568720407097; Tue, 17 Sep 2019 04:40:07 -0700 (PDT) Received: from andrea.guest.corp.microsoft.com ([2a01:110:8012:1010:2dc3:b64e:d9d3:5630]) by smtp.gmail.com with ESMTPSA id q192sm2157683wme.23.2019.09.17.04.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Sep 2019 04:40:06 -0700 (PDT) Date: Tue, 17 Sep 2019 13:39:59 +0200 From: Andrea Parri To: Alan Stern Cc: LKMM Maintainers -- Akira Yokosawa , Boqun Feng , Daniel Lustig , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Will Deacon , Kernel development list Subject: Re: [PATCH RFC] tools/memory-model: Fix data race detection for unordered store and load Message-ID: <20190917113959.GA19404@andrea.guest.corp.microsoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 06, 2019 at 04:57:22PM -0400, Alan Stern wrote: > 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 Acked-by: Andrea Parri Thanks, Andrea > > --- > > 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 >