Received: by 10.192.165.156 with SMTP id m28csp1038449imm; Wed, 18 Apr 2018 02:59:28 -0700 (PDT) X-Google-Smtp-Source: AIpwx49N2+h69c0CZ9j5yNJyIHPeHxFQ0TYFYevOOO9LwbRiA2h/J27DEfSl8YuOB042UkdN29dD X-Received: by 10.98.61.84 with SMTP id k81mr1370327pfa.193.1524045568479; Wed, 18 Apr 2018 02:59:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524045568; cv=none; d=google.com; s=arc-20160816; b=EHBy8DAbT64OT7cgrZD3ALf19mxPAUCgCPPiz+GHx7n+WPFhMR6ItzrjxC6eatr568 8s8d96GhqYRGZkwpB+A44xXcY992Itr7zA8lrozgfRsisJMQzzuqo19N5PZ0i0649KFf D/ws2cr1YM8PqBq9Rg3h+bCdOCNOnF8f7exv9jOKZLedoa1EISzrVaOeonv0pNsr/QUr IWzct3LBBetIKXXkwRGYXOofWFINXlKbpHTLIDoX9LKrFpinZqHSO309bIjAuouvMvur 933xnjsBdoHViVb86m04IZ7DP/ZKRr3GuMOGRcVeJtnScIxllMxprApNZLfK34m6Aoiw 7vhw== 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:arc-authentication-results; bh=BqEw/3QbM44pzRpoHyalOBCryKu3++LfBKimtp9GeVQ=; b=RJVgradIQcwMWlQrEqtjqjrEhLwQfGDgzq7eJUyaMl1jfsCk5v6JEtI2LxQqPc+f5I zUHcdGsuVLFjaVJs7jprhp26B09Mdn9fWXjV22R0L76dnjddouztyqVwfk8j9f4DBsmd ImAQA71vy2CEolrmVJOado2JtO6rSZ17QB9mFHlJgrU0L9VNhkou/n3SUr8sFZH0TjG2 goDl8/xosDlSGwgKXon9Gl0aaEheRNk0WtftnZ76ShzFqtQClOqT0mzU0cHnK8vVrTkN MogC6EyhIyXQ+xSzTwCbOUykxtaEp6xS1yrCNcTZm5xvj71UUG/mvJoJ0MyN51iFAfyu UoOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=lGFmdUhb; 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 t29si791027pgo.539.2018.04.18.02.59.13; Wed, 18 Apr 2018 02:59:28 -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=@amarulasolutions.com header.s=google header.b=lGFmdUhb; 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 S1752630AbeDRJ6H (ORCPT + 99 others); Wed, 18 Apr 2018 05:58:07 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:46426 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751870AbeDRJ6E (ORCPT ); Wed, 18 Apr 2018 05:58:04 -0400 Received: by mail-wr0-f193.google.com with SMTP id d1-v6so3095078wrj.13 for ; Wed, 18 Apr 2018 02:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=BqEw/3QbM44pzRpoHyalOBCryKu3++LfBKimtp9GeVQ=; b=lGFmdUhbm+PCB/1YHBkGVWijQ1jd1FyPs4mkrvZQ/MysIhbRCshKkVWoLlDO9uYTr8 gC2wmifTyni8o6pq1uIyhgQGIRWQ3lXHNXeOYmWnQFwn4yQJXPw3gr2XkD0m4jBqyVtH wJxJ20aL/NK/xjb9n9qEiCmMAAMJVbEXIX8wI= 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=BqEw/3QbM44pzRpoHyalOBCryKu3++LfBKimtp9GeVQ=; b=siynk8b2y/gifUOlTshoI8iiEdkEQH8bJWwUko2zXML27MFMUvd5Z7K/AnJ+YsSPTJ 9Q4ehw02qF6unxeT8DpOpKHKnWtZzXpjHOuxHQmPk2N101KfI+As8cO7jeNKzXDn+TV7 fg7MRrvIfpvCcmP+sSvuZ/kyUHK66NOmKDw05KdzY3FI6kYOboBsM924bGr2n9X0Cs2Z H48Lb+dQaVe2cbFSAfErXDVW5ZnO9vYK0SmbVst+zTx2pH4Nyy+7zkBgvYGxKHyhznPD n9N8rD6fFrQ22IesLIHpbhTe4bjLA+btcaIKSVN3hBNzcBqDgz3xTK2GTDfL6Q/KN5YN kXaw== X-Gm-Message-State: ALQs6tD/SO8yU+ETHOwVAWUq0pmgFfOCANrRaQds0opkMVBhyhnUqYdm qsMt0m+hXdYbK06yhOu3Bl6805J6 X-Received: by 10.28.36.3 with SMTP id k3mr1354589wmk.51.1524045482991; Wed, 18 Apr 2018 02:58:02 -0700 (PDT) Received: from andrea (nat-wifi.sssup.it. [193.205.81.22]) by smtp.gmail.com with ESMTPSA id u138sm1505259wmu.24.2018.04.18.02.58.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 02:58:02 -0700 (PDT) Date: Wed, 18 Apr 2018 11:57:59 +0200 From: Andrea Parri To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@kernel.org, stern@rowland.harvard.edu, parri.andrea@gmail.com, will.deacon@arm.com, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, Ingo Molnar Subject: Re: [PATCH RFC tools/memory-model 4/5] tools/memory-model: Add model support for spin_is_locked Message-ID: <20180418095759.GB3409@andrea> References: <20180416162228.GA18167@linux.vnet.ibm.com> <1523895771-19224-4-git-send-email-paulmck@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1523895771-19224-4-git-send-email-paulmck@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 16, 2018 at 09:22:50AM -0700, Paul E. McKenney wrote: > From: Luc Maranget > > This commit first adds a trivial macro for spin_is_locked() to > linux-kernel.def. > > It also adds cat code for enumerating all possible matches of lock > write events (set LKW) with islocked events returning true (set RL, > for Read from Lock), and unlock write events (set UL) with islocked > events returning false (set RU, for Read from Unlock). Note that this > intentionally does not model uniprocessor kernels (CONFIG_SMP=n) built > with CONFIG_DEBUG_SPINLOCK=n, in which spin_is_locked() unconditionally > returns zero. > > It also adds a pair of litmus tests demonstrating the minimal ordering > provided by spin_is_locked() in conjunction with spin_lock(). Will Deacon > noted that this minimal ordering happens on ARMv8: > https://lkml.kernel.org/r/20180226162426.GB17158@arm.com > > Notice that herd7 installations strictly older than version 7.49 > do not handle the new constructs. > > Signed-off-by: Luc Maranget > Cc: Alan Stern > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Nicholas Piggin > Cc: David Howells > Cc: Jade Alglave > Cc: Luc Maranget > Cc: "Paul E. McKenney" > Cc: Akira Yokosawa > Cc: Ingo Molnar > Signed-off-by: Paul E. McKenney I understand that it's acceptable to not list all maintainers in the commit message, but that does look like an omission... > --- > tools/memory-model/linux-kernel.def | 1 + > .../MP+polockmbonce+poacquiresilsil.litmus | 30 ++++++++++++ > .../MP+polockonce+poacquiresilsil.litmus | 29 ++++++++++++ > tools/memory-model/litmus-tests/README | 10 ++++ > tools/memory-model/lock.cat | 53 ++++++++++++++++++++-- > 5 files changed, 119 insertions(+), 4 deletions(-) > create mode 100644 tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus > create mode 100644 tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus > > diff --git a/tools/memory-model/linux-kernel.def b/tools/memory-model/linux-kernel.def > index 6bd3bc431b3d..f0553bd37c08 100644 > --- a/tools/memory-model/linux-kernel.def > +++ b/tools/memory-model/linux-kernel.def > @@ -38,6 +38,7 @@ cmpxchg_release(X,V,W) __cmpxchg{release}(X,V,W) > spin_lock(X) { __lock(X); } > spin_unlock(X) { __unlock(X); } > spin_trylock(X) __trylock(X) > +spin_is_locked(X) __islocked(X) > > // RCU > rcu_read_lock() { __fence{rcu-lock}; } > diff --git a/tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus b/tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus > new file mode 100644 > index 000000000000..37357404a08d > --- /dev/null > +++ b/tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus > @@ -0,0 +1,30 @@ > +C MP+polockmbonce+poacquiresilsil > + > +(* > + * Result: Never > + * > + * Do spinlocks combined with smp_mb__after_spinlock() provide order > + * to outside observers using spin_is_locked() to sense the lock-held > + * state, ordered by acquire? Note that when the first spin_is_locked() > + * returns false and the second true, we know that the smp_load_acquire() > + * executed before the lock was acquired (loosely speaking). > + *) > + > +{ > +} > + > +P0 (spinlock_t *lo, int *x) { > + spin_lock(lo); > + smp_mb__after_spinlock(); > + WRITE_ONCE(*x,1); > + spin_unlock(lo); > +} > + > +P1 (spinlock_t *lo, int *x) { > + int r1; int r2; int r3; > + r1 = smp_load_acquire(x); > + r2 = spin_is_locked(lo); > + r3 = spin_is_locked(lo); > +} > + > +exists (1:r1=1 /\ 1:r2=0 /\ 1:r3=1) > diff --git a/tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus b/tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus > new file mode 100644 > index 000000000000..ebc2668f95ff > --- /dev/null > +++ b/tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus > @@ -0,0 +1,29 @@ > +C MP+polockonce+poacquiresilsil > + > +(* > + * Result: Sometimes > + * > + * Do spinlocks provide order to outside observers using spin_is_locked() > + * to sense the lock-held state, ordered by acquire? Note that when the > + * first spin_is_locked() returns false and the second true, we know that > + * the smp_load_acquire() executed before the lock was acquired (loosely > + * speaking). > + *) > + > +{ > +} > + > +P0 (spinlock_t *lo, int *x) { > + spin_lock(lo); > + WRITE_ONCE(*x,1); > + spin_unlock(lo); > +} > + > +P1 (spinlock_t *lo, int *x) { > + int r1; int r2; int r3; > + r1 = smp_load_acquire(x); > + r2 = spin_is_locked(lo); > + r3 = spin_is_locked(lo); > +} > + > +exists (1:r1=1 /\ 1:r2=0 /\ 1:r3=1) Please fix the style in the above litmus tests (c.f., e.g., your 2/5). > diff --git a/tools/memory-model/litmus-tests/README b/tools/memory-model/litmus-tests/README > index 04096fb8b8d9..6919909bbd0f 100644 > --- a/tools/memory-model/litmus-tests/README > +++ b/tools/memory-model/litmus-tests/README > @@ -63,6 +63,16 @@ LB+poonceonces.litmus > MP+onceassign+derefonce.litmus > As below, but with rcu_assign_pointer() and an rcu_dereference(). > > +MP+polockmbonce+poacquiresilsil.litmus > + Protect the access with a lock and an smp_mb__after_spinlock() > + in one process, and use an acquire load followed by a pair of > + spin_is_locked() calls in the other process. > + > +MP+polockonce+poacquiresilsil.litmus > + Protect the access with a lock in one process, and use an > + acquire load followed by a pair of spin_is_locked() calls > + in the other process. > + > MP+polocks.litmus > As below, but with the second access of the writer process > and the first access of reader process protected by a lock. > diff --git a/tools/memory-model/lock.cat b/tools/memory-model/lock.cat > index ba4a4ec6d313..3b1439edc818 100644 > --- a/tools/memory-model/lock.cat > +++ b/tools/memory-model/lock.cat > @@ -5,7 +5,11 @@ > *) > > (* Generate coherence orders and handle lock operations *) > - > +(* > + * Warning, crashes with herd7 versions strictly before 7.48. > + * spin_islocked is functional from version 7.49. > + * > + *) > include "cross.cat" > > (* From lock reads to their partner lock writes *) > @@ -32,12 +36,16 @@ flag ~empty [M \ IW] ; loc ; [ALL-LOCKS] as mixed-lock-accesses > (* The final value of a spinlock should not be tested *) > flag ~empty [FW] ; loc ; [ALL-LOCKS] as lock-final > > - > +(* > + * Backward compatibility > + *) > +let RL = try RL with emptyset (* defined herd7 >= 7.49 *) > +let RU = try RU with emptyset (* defined herd7 >= 7.49 *) > (* > * Put lock operations in their appropriate classes, but leave UL out of W > * until after the co relation has been generated. > *) > -let R = R | LKR | LF > +let R = R | LKR | LF | RL | RU > let W = W | LKW > > let Release = Release | UL > @@ -72,8 +80,45 @@ let all-possible-rfe-lf = > > (* Generate all rf relations for LF events *) > with rfe-lf from cross(all-possible-rfe-lf) > -let rf = rf | rfi-lf | rfe-lf > > +let rf-lf = rfe-lf | rfi-lf > + > +(* rf for RL events, ie islocked returning true, similar to LF above *) > + > +(* islocked returning true inside a critical section > + * must read from the opening lock > + *) > +let rfi-rl = ([LKW] ; po-loc ; [RL]) \ ([LKW] ; po-loc ; [UL] ; po-loc) > + > +(* islocked returning true outside critical sections can match any > + * external lock. > + *) multi-lines comments are (* * line * line *) > +let all-possible-rfe-rl = > + let possible-rfe-lf r = > + let pair-to-relation p = p ++ 0 > + in map pair-to-relation ((LKW * {r}) & loc & ext) > + in map possible-rfe-lf (RL \ range(rfi-rl)) > + > +with rfe-rl from cross(all-possible-rfe-rl) > +let rf-rl = rfe-rl | rfi-rl > + > +(* Read from unlock, ie islocked returning false, slightly different *) > + > +(* islocked returning false can read from the last po-previous unlock *) > +let rfi-ru = ([UL] ; po-loc ; [RU]) \ ([UL] ; po-loc ; [LKW] ; po-loc) > + > +(* any islocked returning false can read from any external unlock *) > +let all-possible-rfe-ru = > + let possible-rfe-ru r = please fix the alignment/indentation > + let pair-to-relation p = p ++ 0 > + in map pair-to-relation (((UL|IW) * {r}) & loc & ext) spaces around binary operators ^^^^ Andrea > + in map possible-rfe-ru RU > + > +with rfe-ru from cross(all-possible-rfe-ru) > +let rf-ru = rfe-ru | rfi-ru > + > +(* Final rf relation *) > +let rf = rf | rf-lf | rf-rl | rf-ru > > (* Generate all co relations, including LKW events but not UL *) > let co0 = co0 | ([IW] ; loc ; [LKW]) | > -- > 2.5.2 >