[tip: locking/core] tools/memory-model: Remove reference to atomic_ops.rst
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 9146658cc49a1dbed5ece140f658be884e189ade
Gitweb:
https://git.kernel.org/tip/9146658cc49a1dbed5ece140f658be884e189ade
Author:Akira Yokosawa
AuthorDate:Thu, 14 Jan 2021 23:09:07 +09:00
Committer: Paul E. McKenney
CommitterDate: Mon, 08 Mar 2021 14:29:22 -08:00
tools/memory-model: Remove reference to atomic_ops.rst
atomic_ops.rst was removed by commit f0400a77ebdc ("atomic: Delete
obsolete documentation").
Remove the broken link in tools/memory-model/Documentation/simple.txt.
Cc: Peter Zijlstra
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney
---
tools/memory-model/Documentation/simple.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/memory-model/Documentation/simple.txt
b/tools/memory-model/Documentation/simple.txt
index 81e1a0e..4c789ec 100644
--- a/tools/memory-model/Documentation/simple.txt
+++ b/tools/memory-model/Documentation/simple.txt
@@ -189,7 +189,6 @@ Additional information may be found in these files:
Documentation/atomic_t.txt
Documentation/atomic_bitops.txt
-Documentation/core-api/atomic_ops.rst
Documentation/core-api/refcount-vs-atomic.rst
Reading code using these primitives is often also quite helpful.
[tip: core/rcu] rculist: Replace reference to atomic_ops.rst
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 5bb1369d4bea078dd1298dfc2c6ce781d9e34dde
Gitweb:
https://git.kernel.org/tip/5bb1369d4bea078dd1298dfc2c6ce781d9e34dde
Author:Akira Yokosawa
AuthorDate:Sat, 16 Jan 2021 00:11:45 +09:00
Committer: Paul E. McKenney
CommitterDate: Mon, 08 Mar 2021 14:17:35 -08:00
rculist: Replace reference to atomic_ops.rst
The hlist_nulls_for_each_entry_rcu() docbook header references the
atomic_ops.rst file, which was removed in commit f0400a77ebdc ("atomic:
Delete obsolete documentation"). This commit therefore substitutes a
section in memory-barriers.txt discussing the use of barrier() in loops.
Cc: Peter Zijlstra
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney
---
include/linux/rculist_nulls.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rculist_nulls.h b/include/linux/rculist_nulls.h
index ff3e947..d8afdb8 100644
--- a/include/linux/rculist_nulls.h
+++ b/include/linux/rculist_nulls.h
@@ -161,7 +161,7 @@ static inline void hlist_nulls_add_fake(struct
hlist_nulls_node *n)
*
* The barrier() is needed to make sure compiler doesn't cache first element
[1],
* as this loop can be restarted [2]
- * [1] Documentation/core-api/atomic_ops.rst around line 114
+ * [1] Documentation/memory-barriers.txt around line 1533
* [2] Documentation/RCU/rculist_nulls.rst around line 146
*/
#define hlist_nulls_for_each_entry_rcu(tpos, pos, head, member)
\
[tip: locking/core] tools/memory-model: Fix typo in klitmus7 compatibility table
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 3d5c70329b910ab583673a33e3a615873c5d4115
Gitweb:
https://git.kernel.org/tip/3d5c70329b910ab583673a33e3a615873c5d4115
Author:Akira Yokosawa
AuthorDate:Sat, 28 Nov 2020 14:32:15 +09:00
Committer: Paul E. McKenney
CommitterDate: Mon, 04 Jan 2021 14:40:50 -08:00
tools/memory-model: Fix typo in klitmus7 compatibility table
klitmus7 of herdtools7 7.48 or earlier depends on ACCESS_ONCE(),
which was removed in Linux v4.15.
Fix the obvious typo in the table.
Fixes: d075a78a5ab1 ("tools/memory-model/README: Expand dependency of klitmus7")
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney
---
tools/memory-model/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/memory-model/README b/tools/memory-model/README
index 39d08d1..9a84c45 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -51,7 +51,7 @@ klitmus7 Compatibility Table
==
target Linux herdtools7
--
--- 4.18 7.48 --
+-- 4.14 7.48 --
4.15 -- 4.19 7.49 --
4.20 -- 5.5 7.54 --
5.6 -- 7.56 --
[tip: locking/core] tools/memory-model: Remove redundant initialization in litmus tests
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 5c587f9b9c35850f9da3c425f98dc53ab1cde9f3
Gitweb:
https://git.kernel.org/tip/5c587f9b9c35850f9da3c425f98dc53ab1cde9f3
Author:Akira Yokosawa
AuthorDate:Sat, 28 Nov 2020 08:43:45 +09:00
Committer: Paul E. McKenney
CommitterDate: Mon, 04 Jan 2021 14:40:49 -08:00
tools/memory-model: Remove redundant initialization in litmus tests
This is a revert of commit 1947bfcf81a9 ("tools/memory-model: Add types
to litmus tests") with conflict resolutions.
klitmus7 [1] is aware of default types of "int" and "int*".
It accepts litmus tests for herd7 without extra type info unless
non-"int" variables are referenced by an "exists", "locations",
or "filter" directive.
[1]: Tested with klitmus7 versions 7.49 or later.
Suggested-by: Paul E. McKenney
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney
---
tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
| 4 +---
tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
| 4 +---
tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
| 4 +---
tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
| 4 +---
tools/memory-model/litmus-tests/IRIW+fencembonceonces+OnceOnce.litmus
| 5 +
tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus
| 5 +
tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus
| 7 +--
tools/memory-model/litmus-tests/ISA2+poonceonces.litmus
| 6 +-
tools/memory-model/litmus-tests/ISA2+pooncerelease+poacquirerelease+poacquireonce.litmus
| 6 +-
tools/memory-model/litmus-tests/LB+fencembonceonce+ctrlonceonce.litmus
| 5 +
tools/memory-model/litmus-tests/LB+poacquireonce+pooncerelease.litmus
| 5 +
tools/memory-model/litmus-tests/LB+poonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/MP+fencewmbonceonce+fencermbonceonce.litmus
| 5 +
tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus
| 4 +---
tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus
| 5 +
tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus
| 5 +
tools/memory-model/litmus-tests/MP+polocks.litmus
| 6 +-
tools/memory-model/litmus-tests/MP+poonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/MP+pooncerelease+poacquireonce.litmus
| 5 +
tools/memory-model/litmus-tests/MP+porevlocks.litmus
| 6 +-
tools/memory-model/litmus-tests/R+fencembonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/R+poonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/S+fencewmbonceonce+poacquireonce.litmus
| 5 +
tools/memory-model/litmus-tests/S+poonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/SB+fencembonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/SB+poonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/SB+rfionceonce-poonceonces.litmus
| 5 +
tools/memory-model/litmus-tests/WRC+poonceonces+Once.litmus
| 5 +
tools/memory-model/litmus-tests/WRC+pooncerelease+fencermbonceonce+Once.litmus
| 5 +
tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus
| 7 +--
tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
| 7 +--
tools/memory-model/litmus-tests/Z6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus
| 6 +-
32 files changed, 32 insertions(+), 134 deletions(-)
diff --git a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
index 772544f..967f9f2 100644
--- a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
+++ b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
@@ -7,9 +7,7 @@ C CoRR+poonceonce+Once
* reads from the same variable are ordered.
*)
-{
- int x;
-}
+{}
P0(int *x)
{
diff --git a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
index 5faae98..4635739 100644
--- a/tools/memory-model/litmus-tests/
[PATCH -rcu] rculist: Replace reference to atomic_ops.rst
>From f92cae321e9a42a1d4bc8a2d5d1a2cd62ab35410 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Fri, 15 Jan 2021 23:39:03 +0900
Subject: [PATCH -rcu] rculist: Replace reference to atomic_ops.rst
atomic_ops.rst was removed in commit f0400a77ebdc ("atomic: Delete
obsolete documentation").
Instead, reference a section in memory-barriers.txt discussing
the use of barrier() in loops.
Cc: Peter Zijlstra
Signed-off-by: Akira Yokosawa
---
include/linux/rculist_nulls.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rculist_nulls.h b/include/linux/rculist_nulls.h
index ff3e94779e73..d8afdb8784c1 100644
--- a/include/linux/rculist_nulls.h
+++ b/include/linux/rculist_nulls.h
@@ -161,7 +161,7 @@ static inline void hlist_nulls_add_fake(struct
hlist_nulls_node *n)
*
* The barrier() is needed to make sure compiler doesn't cache first element
[1],
* as this loop can be restarted [2]
- * [1] Documentation/core-api/atomic_ops.rst around line 114
+ * [1] Documentation/memory-barriers.txt around line 1533
* [2] Documentation/RCU/rculist_nulls.rst around line 146
*/
#define hlist_nulls_for_each_entry_rcu(tpos, pos, head, member)
\
--
2.17.1
[PATCH -rcu] tools/memory-model: Remove reference to atomic_ops.rst
>From 1d7642add7f74ca307f1bf70569e23edf8b1a023 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Thu, 14 Jan 2021 23:09:07 +0900
Subject: [PATCH -rcu] tools/memory-model: Remove reference to atomic_ops.rst
atomic_ops.rst was removed by commit f0400a77ebdc ("atomic: Delete
obsolete documentation").
Remove the broken link in tools/memory-model/Documentation/simple.txt.
Cc: Peter Zijlstra
Signed-off-by: Akira Yokosawa
---
Hi Paul,
This is relative to dev of -rcu.
Thanks, Akira
--
tools/memory-model/Documentation/simple.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/memory-model/Documentation/simple.txt
b/tools/memory-model/Documentation/simple.txt
index 81e1a0ec5342..4c789ec8334f 100644
--- a/tools/memory-model/Documentation/simple.txt
+++ b/tools/memory-model/Documentation/simple.txt
@@ -189,7 +189,6 @@ Additional information may be found in these files:
Documentation/atomic_t.txt
Documentation/atomic_bitops.txt
-Documentation/core-api/atomic_ops.rst
Documentation/core-api/refcount-vs-atomic.rst
Reading code using these primitives is often also quite helpful.
--
2.17.1
Re: [PATCH memory-model 6/8] tools/memory-model: Add types to litmus tests
On Fri, 27 Nov 2020 07:46:52 -0800, Paul E. McKenney wrote: > On Wed, Nov 25, 2020 at 08:34:47PM +0900, Akira Yokosawa wrote: [...] >> Hi Paul, >> >> I'm seeing this patch still alive in the updated for-mingo-lkmm branch. >> Have you got some objection? > > From git, which was not able to trivially revert. ;-) ;-) > If you send me a > patch on top that removes the uneeded declarations and if someone > tests it with a klitmus run, I will take it for the merge window > following the upcoming one. Got it! I'm submitting a patch set in reply to this mail. 1/2 is the removal of those redundant type declarations. 2/2 is an obvious fix of typo I made in the klitmus7 compat table. Thanks, Akira > > Thanx, Paul > >> Thanks, Akira >>
[PATCH 1/2] tools/memory-model: Remove redundant initialization in litmus tests
>From 3a871845825d96a23d64be05b6cf6d4af2bae167 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sat, 28 Nov 2020 08:43:45 +0900
Subject: [PATCH 1/2] tools/memory-model: Remove redundant initialization in
litmus tests
This is a revert of commit 1947bfcf81a9 ("tools/memory-model: Add types
to litmus tests") with conflict resolutions.
klitmus7 [1] is aware of default types of "int" and "int*".
It accepts litmus tests for herd7 without extra type info unless
non-"int" variables are referenced by an "exists", "locations",
or "filter" directive.
[1]: Tested with klitmus7 versions 7.49 or later.
Suggested-by: Paul E. McKenney
Signed-off-by: Akira Yokosawa
---
.../memory-model/litmus-tests/CoRR+poonceonce+Once.litmus | 4 +---
.../memory-model/litmus-tests/CoRW+poonceonce+Once.litmus | 4 +---
.../memory-model/litmus-tests/CoWR+poonceonce+Once.litmus | 4 +---
tools/memory-model/litmus-tests/CoWW+poonceonce.litmus | 4 +---
.../litmus-tests/IRIW+fencembonceonces+OnceOnce.litmus | 5 +
.../litmus-tests/IRIW+poonceonces+OnceOnce.litmus | 5 +
.../ISA2+pooncelock+pooncelock+pombonce.litmus | 7 +--
tools/memory-model/litmus-tests/ISA2+poonceonces.litmus| 6 +-
...SA2+pooncerelease+poacquirerelease+poacquireonce.litmus | 6 +-
.../litmus-tests/LB+fencembonceonce+ctrlonceonce.litmus| 5 +
.../litmus-tests/LB+poacquireonce+pooncerelease.litmus | 5 +
tools/memory-model/litmus-tests/LB+poonceonces.litmus | 5 +
.../MP+fencewmbonceonce+fencermbonceonce.litmus| 5 +
.../litmus-tests/MP+onceassign+derefonce.litmus| 4 +---
.../litmus-tests/MP+polockmbonce+poacquiresilsil.litmus| 5 +
.../litmus-tests/MP+polockonce+poacquiresilsil.litmus | 5 +
tools/memory-model/litmus-tests/MP+polocks.litmus | 6 +-
tools/memory-model/litmus-tests/MP+poonceonces.litmus | 5 +
.../litmus-tests/MP+pooncerelease+poacquireonce.litmus | 5 +
tools/memory-model/litmus-tests/MP+porevlocks.litmus | 6 +-
tools/memory-model/litmus-tests/R+fencembonceonces.litmus | 5 +
tools/memory-model/litmus-tests/R+poonceonces.litmus | 5 +
.../litmus-tests/S+fencewmbonceonce+poacquireonce.litmus | 5 +
tools/memory-model/litmus-tests/S+poonceonces.litmus | 5 +
tools/memory-model/litmus-tests/SB+fencembonceonces.litmus | 5 +
tools/memory-model/litmus-tests/SB+poonceonces.litmus | 5 +
.../litmus-tests/SB+rfionceonce-poonceonces.litmus | 5 +
.../memory-model/litmus-tests/WRC+poonceonces+Once.litmus | 5 +
.../WRC+pooncerelease+fencermbonceonce+Once.litmus | 5 +
.../Z6.0+pooncelock+poonceLock+pombonce.litmus | 7 +--
.../Z6.0+pooncelock+pooncelock+pombonce.litmus | 7 +--
...0+pooncerelease+poacquirerelease+fencembonceonce.litmus | 6 +-
32 files changed, 32 insertions(+), 134 deletions(-)
diff --git a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
index 772544f03fb5..967f9f2a6226 100644
--- a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
+++ b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
@@ -7,9 +7,7 @@ C CoRR+poonceonce+Once
* reads from the same variable are ordered.
*)
-{
- int x;
-}
+{}
P0(int *x)
{
diff --git a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
index 5faae98f7ffb..4635739f3974 100644
--- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
+++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
@@ -7,9 +7,7 @@ C CoRW+poonceonce+Once
* a given variable and a later write to that same variable are ordered.
*)
-{
- int x;
-}
+{}
P0(int *x)
{
diff --git a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
index 77c9cc9f8dc6..bb068c92d8da 100644
--- a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
+++ b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
@@ -7,9 +7,7 @@ C CoWR+poonceonce+Once
* given variable and a later read from that same variable are ordered.
*)
-{
- int x;
-}
+{}
P0(int *x)
{
diff --git a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
index 85ef746f511a..0d9f0a958799 100644
--- a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
+++ b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
@@ -7,9 +7,7 @@ C CoWW+poonceonce
* writes to the same variable are ordered.
*)
-{
- int x;
-}
+{}
P0(int *x)
{
diff --git
a/tools/memory-model/litmus-tests/IRIW+fencembonceonces+OnceOnce.litmus
b/tools/memory-model/litmus-tests/IRIW+fencembonceonces+OnceOnce.litmu
[PATCH 2/2] tools/memory-model: Fix typo in klitmus7 compatibility table
>From 4f577823fa60e14ae58caa2d3c0b2ced64e6eb43 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sat, 28 Nov 2020 14:32:15 +0900
Subject: [PATCH 2/2] tools/memory-model: Fix typo in klitmus7 compatibility
table
klitmus7 of herdtools7 7.48 or earlier depends on ACCESS_ONCE(),
which was removed in Linux v4.15.
Fix the obvious typo in the table.
Fixes: d075a78a5ab1 ("tools/memory-model/README: Expand dependency of klitmus7")
Signed-off-by: Akira Yokosawa
---
tools/memory-model/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/memory-model/README b/tools/memory-model/README
index 39d08d1f0443..9a84c45504ab 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -51,7 +51,7 @@ klitmus7 Compatibility Table
==
target Linux herdtools7
--
--- 4.18 7.48 --
+-- 4.14 7.48 --
4.15 -- 4.19 7.49 --
4.20 -- 5.5 7.54 --
5.6 -- 7.56 --
--
2.17.1
Re: [PATCH memory-model 6/8] tools/memory-model: Add types to litmus tests
On Thu, 5 Nov 2020 14:56:05 -0800, Paul E. McKenney wrote: > On Fri, Nov 06, 2020 at 07:41:48AM +0900, Akira Yokosawa wrote: >> Hi Paul, >> >> On 2020/11/06 7:00, paul...@kernel.org wrote: >>> From: "Paul E. McKenney" >>> >>> This commit adds type information for global variables in the litmus >>> tests in order to allow easier use with klitmus7. >> >> IIUC, klitmus7 is happy with existing litmus tests under tools/memory-model. >> So I don't think this change is necessary. >> >> As a matter of fact, I was preparing a patch set to empty most of the >> initialization blocks in perfbook's CodeSamples/formal/ litmus tests. > > Heh! Someone asked for this change several months back, and I failed > to record who it was. If they don't object, I will remove this patch. Hi Paul, I'm seeing this patch still alive in the updated for-mingo-lkmm branch. Have you got some objection? Thanks, Akira > > Thanx, Paul > >>> >>> Signed-off-by: Paul E. McKenney >>> --- >>> tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus| 4 +++- >>> tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus| 4 +++- >>> tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus| 4 +++- >>> tools/memory-model/litmus-tests/CoWW+poonceonce.litmus | 4 +++- >>> .../litmus-tests/IRIW+fencembonceonces+OnceOnce.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus | 5 >>> - >>> .../litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus| 7 >>> ++- >>> tools/memory-model/litmus-tests/ISA2+poonceonces.litmus| 6 >>> +- >>> .../ISA2+pooncerelease+poacquirerelease+poacquireonce.litmus | 6 >>> +- >>> .../litmus-tests/LB+fencembonceonce+ctrlonceonce.litmus| 5 >>> - >>> .../litmus-tests/LB+poacquireonce+pooncerelease.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/LB+poonceonces.litmus | 5 >>> - >>> .../litmus-tests/MP+fencewmbonceonce+fencermbonceonce.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus | 5 >>> +++-- >>> .../litmus-tests/MP+polockmbonce+poacquiresilsil.litmus| 2 ++ >>> .../memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus | 2 ++ >>> tools/memory-model/litmus-tests/MP+polocks.litmus | 6 >>> +- >>> tools/memory-model/litmus-tests/MP+poonceonces.litmus | 5 >>> - >>> .../litmus-tests/MP+pooncerelease+poacquireonce.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/MP+porevlocks.litmus | 6 >>> +- >>> tools/memory-model/litmus-tests/R+fencembonceonces.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/R+poonceonces.litmus | 5 >>> - >>> .../litmus-tests/S+fencewmbonceonce+poacquireonce.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/S+poonceonces.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/SB+fencembonceonces.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/SB+poonceonces.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/SB+rfionceonce-poonceonces.litmus | 5 >>> - >>> tools/memory-model/litmus-tests/WRC+poonceonces+Once.litmus| 5 >>> - >>> .../litmus-tests/WRC+pooncerelease+fencermbonceonce+Once.litmus| 5 >>> - >>> .../litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus| 7 >>> ++- >>> .../litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus| 7 >>> ++- >>> .../Z6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus | 6 >>> +- >>> 32 files changed, 130 insertions(+), 31 deletions(-) >>> >>> diff --git a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus >>> b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus >>> index 967f9f2..772544f 100644 >>> --- a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus >>> +++ b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus >>> @@ -7,7 +7,9 @@ C CoRR+poonceonce+Once >>> * reads from the same var
Re: [PATCH memory-model 6/8] tools/memory-model: Add types to litmus tests
Hi Paul,
On 2020/11/06 7:00, paul...@kernel.org wrote:
> From: "Paul E. McKenney"
>
> This commit adds type information for global variables in the litmus
> tests in order to allow easier use with klitmus7.
IIUC, klitmus7 is happy with existing litmus tests under tools/memory-model.
So I don't think this change is necessary.
As a matter of fact, I was preparing a patch set to empty most of the
initialization blocks in perfbook's CodeSamples/formal/ litmus tests.
Thanks, Akira
>
> Signed-off-by: Paul E. McKenney
> ---
> tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus| 4 +++-
> tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus| 4 +++-
> tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus| 4 +++-
> tools/memory-model/litmus-tests/CoWW+poonceonce.litmus | 4 +++-
> .../litmus-tests/IRIW+fencembonceonces+OnceOnce.litmus | 5 -
> tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus | 5 -
> .../litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus| 7
> ++-
> tools/memory-model/litmus-tests/ISA2+poonceonces.litmus| 6 +-
> .../ISA2+pooncerelease+poacquirerelease+poacquireonce.litmus | 6 +-
> .../litmus-tests/LB+fencembonceonce+ctrlonceonce.litmus| 5 -
> .../litmus-tests/LB+poacquireonce+pooncerelease.litmus | 5 -
> tools/memory-model/litmus-tests/LB+poonceonces.litmus | 5 -
> .../litmus-tests/MP+fencewmbonceonce+fencermbonceonce.litmus | 5 -
> tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus | 5 +++--
> .../litmus-tests/MP+polockmbonce+poacquiresilsil.litmus| 2 ++
> .../memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus | 2 ++
> tools/memory-model/litmus-tests/MP+polocks.litmus | 6 +-
> tools/memory-model/litmus-tests/MP+poonceonces.litmus | 5 -
> .../litmus-tests/MP+pooncerelease+poacquireonce.litmus | 5 -
> tools/memory-model/litmus-tests/MP+porevlocks.litmus | 6 +-
> tools/memory-model/litmus-tests/R+fencembonceonces.litmus | 5 -
> tools/memory-model/litmus-tests/R+poonceonces.litmus | 5 -
> .../litmus-tests/S+fencewmbonceonce+poacquireonce.litmus | 5 -
> tools/memory-model/litmus-tests/S+poonceonces.litmus | 5 -
> tools/memory-model/litmus-tests/SB+fencembonceonces.litmus | 5 -
> tools/memory-model/litmus-tests/SB+poonceonces.litmus | 5 -
> tools/memory-model/litmus-tests/SB+rfionceonce-poonceonces.litmus | 5 -
> tools/memory-model/litmus-tests/WRC+poonceonces+Once.litmus| 5 -
> .../litmus-tests/WRC+pooncerelease+fencermbonceonce+Once.litmus| 5 -
> .../litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus| 7
> ++-
> .../litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus| 7
> ++-
> .../Z6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus | 6 +-
> 32 files changed, 130 insertions(+), 31 deletions(-)
>
> diff --git a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> index 967f9f2..772544f 100644
> --- a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> +++ b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> @@ -7,7 +7,9 @@ C CoRR+poonceonce+Once
> * reads from the same variable are ordered.
> *)
>
> -{}
> +{
> + int x;
> +}
>
> P0(int *x)
> {
> diff --git a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> index 4635739..5faae98 100644
> --- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> +++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> @@ -7,7 +7,9 @@ C CoRW+poonceonce+Once
> * a given variable and a later write to that same variable are ordered.
> *)
>
> -{}
> +{
> + int x;
> +}
>
> P0(int *x)
> {
> diff --git a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> index bb068c9..77c9cc9 100644
> --- a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> +++ b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> @@ -7,7 +7,9 @@ C CoWR+poonceonce+Once
> * given variable and a later read from that same variable are ordered.
> *)
>
> -{}
> +{
> + int x;
> +}
>
> P0(int *x)
> {
> diff --git a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> index 0d9f0a9..85ef746 100644
> --- a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> +++ b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> @@ -7,7 +7,9 @@ C CoWW+poonceonce
> * writes to the same variable are ordered.
> *)
>
> -{}
Re: [PATCH v2 02/24] tools: docs: memory-model: fix references for some files
On Wed, 14 Oct 2020 09:56:03 +0200, Mauro Carvalho Chehab wrote: > Em Tue, 13 Oct 2020 18:58:40 -0700 > "Paul E. McKenney" escreveu: > >> On Tue, Oct 13, 2020 at 12:38:36PM -0400, Alan Stern wrote: >>> On Tue, Oct 13, 2020 at 09:33:54AM -0700, Paul E. McKenney wrote: On Tue, Oct 13, 2020 at 02:14:29PM +0200, Mauro Carvalho Chehab wrote: > - The sysfs.txt file was converted to ReST and renamed; > - The control-dependencies.txt is not at > Documentation/control-dependencies.txt. As it is at the > same dir as the README file, which mentions it, just > remove Documentation/. > > With that, ./scripts/documentation-file-ref-check script > is now happy again for files under tools/. > > Signed-off-by: Mauro Carvalho Chehab Queued for review and testing, likely target v5.11. >>> >>> Instead of changing the path in the README reference, shouldn't >>> tools/memory-model/control-dependencies.txt be moved to its proper >>> position in .../Documentation? >> >> You are of course quite right. My thought is to let Mauro go ahead, >> given his short deadline. We can then make this "git mv" change once >> v5.10-rc1 comes out, given that it should have Mauro's patches. I have >> added a reminder to my calendar. > > Sounds like a plan to me. > > > If it helps on 5.11 plans, converting this file to ReST format is quite > trivial: it just needs to use "::" for C/asm code literal blocks, and > to replace "(*) " by something that matches ReST syntax for lists, > like "(#) " or just "* ": > > > https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#bullet-lists > > See enclosed. I'm afraid conversion of LKMM documents to ReST is unlikely to happen any time soon. It should wait until such time comes when the auto markup tools become clever enough and .rst files looks exactly the same as plain .txt files. Am I asking too much? :-) Thanks, Akira > > Thanks, > Mauro > > [PATCH] convert control-dependencies.rst to ReST > [snip]
Re: Bug in herd7 [Was: Re: Litmus test for question from Al Viro]
On Sat, 3 Oct 2020 13:13:38 -0400, Alan Stern wrote:
> On Sun, Oct 04, 2020 at 12:16:31AM +0900, Akira Yokosawa wrote:
>> Hi Alan,
>>
>> Just a minor nit in the litmus test.
>>
>> On Sat, 3 Oct 2020 09:22:12 -0400, Alan Stern wrote:
>>> To expand on my statement about the LKMM's weakness regarding control
>>> constructs, here is a litmus test to illustrate the issue. You might
>>> want to add this to one of the archives.
>>>
>>> Alan
>>>
>>> C crypto-control-data
>>> (*
>>> * LB plus crypto-control-data plus data
>>> *
>>> * Expected result: allowed
>>> *
>>> * This is an example of OOTA and we would like it to be forbidden.
>>> * The WRITE_ONCE in P0 is both data-dependent and (at the hardware level)
>>> * control-dependent on the preceding READ_ONCE. But the dependencies are
>>> * hidden by the form of the conditional control construct, hence the
>>> * name "crypto-control-data". The memory model doesn't recognize them.
>>> *)
>>>
>>> {}
>>>
>>> P0(int *x, int *y)
>>> {
>>> int r1;
>>>
>>> r1 = 1;
>>> if (READ_ONCE(*x) == 0)
>>> r1 = 0;
>>> WRITE_ONCE(*y, r1);
>>> }
>>>
>>> P1(int *x, int *y)
>>> {
>>> WRITE_ONCE(*x, READ_ONCE(*y));
>>
>> Looks like this one-liner doesn't provide data-dependency of y -> x on herd7.
>
> You're right. This is definitely a bug in herd7.
>
> Luc, were you aware of this?
>
>> When I changed P1 to
>>
>> P1(int *x, int *y)
>> {
>> int r1;
>>
>> r1 = READ_ONCE(*y);
>> WRITE_ONCE(*x, r1);
>> }
>>
>> and replaced the WRITE_ONCE() in P0 with smp_store_release(),
>> I got the result of:
>>
>> -
>> Test crypto-control-data Allowed
>> States 1
>> 0:r1=0;
>> No
>> Witnesses
>> Positive: 0 Negative: 3
>> Condition exists (0:r1=1)
>> Observation crypto-control-data Never 0 3
>> Time crypto-control-data 0.01
>> Hash=9b9aebbaf945dad8183d2be0ccb88e11
>> -
>>
>> Restoring the WRITE_ONCE() in P0, I got the result of:
>>
>> -
>> Test crypto-control-data Allowed
>> States 2
>> 0:r1=0;
>> 0:r1=1;
>> Ok
>> Witnesses
>> Positive: 1 Negative: 4
>> Condition exists (0:r1=1)
>> Observation crypto-control-data Sometimes 1 4
>> Time crypto-control-data 0.01
>> Hash=843eaa4974cec0efae79ce3cb73a1278
>> -
>
> What you should have done was put smp_store_release in P0 and left P1 in
> its original form. That test should not be allowed, but herd7 says that
> it is.
Yea, that was what I tried first, expecting the result of "Never".
>
>> As this is the same as the expected result, I suppose you have missed another
>> limitation of herd7 + LKMM.
>
> It would be more accurate to say that we all missed it. :-) (And it's
> a bug in herd7, not a limitation of either herd7 or LKMM.) How did you
> notice it?
:-) :-) :-)
Well, I thought I had never seen a litmus test with such one-liner.
So I split the READ_ONCE() and WRITE_ONCE() into two lines and
got the expected result.
I don't expect much from herd7's C mode in the first place.
(No offense intended!)
>> By the way, I think this weakness on control dependency + data dependency
>> deserves an entry in tools/memory-model/Documentation/litmus-tests.txt.
>>
>> In the LIMITATIONS section, item #1 mentions some situation where
>> LKMM may not recognize possible losses of control-dependencies by
>> compiler optimizations.
>>
>> What this litmus test demonstrates is a different class of mismatch.
>
> Yes, one in which LKMM does not recognize a genuine dependency because
> it can't tell that some optimizations are not valid.
>
> This flaw is fundamental to the way herd7 works. It examines only one
> execution at a time, and it doesn't consider the code in a conditional
> branch while it's examining an execution where that branch wasn't taken.
> Therefore it has no way to know that the code in the unexecuted branch
> would prevent a certain optimization. But the compiler does consider
> all the code in all branches when deciding what optimizations to apply.
I see.
>
> Here's another trivial example:
>
> r1 = READ_ONCE(*x);
> if (r1 == 0)
> smp_mb();
> WRITE_ONCE(*y, 1);
>
> The compiler can't move the WRITE_ONCE before the READ_ONCE or the "if"
> statement, because it's not allowed to move shared memory accesses past
> a memory barrier -- even if that memory barrier isn't always executed.
> Therefore the WRITE_ONCE actually is ordered after the READ_ONCE, but
> the memory model doesn't realize it.>
>> Alan, can you come up with an update in this regard?
>
> I'll write something.
Thanks!
Akira
>
> Alan
>
Re: Litmus test for question from Al Viro
Hi Alan,
Just a minor nit in the litmus test.
On Sat, 3 Oct 2020 09:22:12 -0400, Alan Stern wrote:
> To expand on my statement about the LKMM's weakness regarding control
> constructs, here is a litmus test to illustrate the issue. You might
> want to add this to one of the archives.
>
> Alan
>
> C crypto-control-data
> (*
> * LB plus crypto-control-data plus data
> *
> * Expected result: allowed
> *
> * This is an example of OOTA and we would like it to be forbidden.
> * The WRITE_ONCE in P0 is both data-dependent and (at the hardware level)
> * control-dependent on the preceding READ_ONCE. But the dependencies are
> * hidden by the form of the conditional control construct, hence the
> * name "crypto-control-data". The memory model doesn't recognize them.
> *)
>
> {}
>
> P0(int *x, int *y)
> {
> int r1;
>
> r1 = 1;
> if (READ_ONCE(*x) == 0)
> r1 = 0;
> WRITE_ONCE(*y, r1);
> }
>
> P1(int *x, int *y)
> {
> WRITE_ONCE(*x, READ_ONCE(*y));
Looks like this one-liner doesn't provide data-dependency of y -> x on herd7.
When I changed P1 to
P1(int *x, int *y)
{
int r1;
r1 = READ_ONCE(*y);
WRITE_ONCE(*x, r1);
}
and replaced the WRITE_ONCE() in P0 with smp_store_release(),
I got the result of:
-
Test crypto-control-data Allowed
States 1
0:r1=0;
No
Witnesses
Positive: 0 Negative: 3
Condition exists (0:r1=1)
Observation crypto-control-data Never 0 3
Time crypto-control-data 0.01
Hash=9b9aebbaf945dad8183d2be0ccb88e11
-
Restoring the WRITE_ONCE() in P0, I got the result of:
-
Test crypto-control-data Allowed
States 2
0:r1=0;
0:r1=1;
Ok
Witnesses
Positive: 1 Negative: 4
Condition exists (0:r1=1)
Observation crypto-control-data Sometimes 1 4
Time crypto-control-data 0.01
Hash=843eaa4974cec0efae79ce3cb73a1278
-
As this is the same as the expected result, I suppose you have missed another
limitation of herd7 + LKMM.
By the way, I think this weakness on control dependency + data dependency
deserves an entry in tools/memory-model/Documentation/litmus-tests.txt.
In the LIMITATIONS section, item #1 mentions some situation where
LKMM may not recognize possible losses of control-dependencies by
compiler optimizations.
What this litmus test demonstrates is a different class of mismatch.
Alan, can you come up with an update in this regard?
Thanks, Akira
> }
>
> exists (0:r1=1)
>
Re: [PATCH kcsan 8/9] tools/memory-model: Document categories of ordering primitives
On Mon, 31 Aug 2020 11:20:36 -0700, paul...@kernel.org wrote: > From: "Paul E. McKenney" > > The Linux kernel has a number of categories of ordering primitives, which > are recorded in the LKMM implementation and hinted at by cheatsheet.txt. > But there is no overview of these categories, and such an overview > is needed in order to understand multithreaded LKMM litmus tests. > This commit therefore adds an ordering.txt as well as extracting a > control-dependencies.txt from memory-barriers.txt. It also updates the > README file. > > Signed-off-by: Paul E. McKenney > --- > tools/memory-model/Documentation/README | 24 +- > tools/memory-model/Documentation/ordering.txt | 462 > ++ > tools/memory-model/control-dependencies.txt | 256 ++ > 3 files changed, 740 insertions(+), 2 deletions(-) > create mode 100644 tools/memory-model/Documentation/ordering.txt > create mode 100644 tools/memory-model/control-dependencies.txt Hi Paul, Didn't you mean to put control-dependencies.txt under tools/memory-model/Documentation/ ? Thanks, Akira > > diff --git a/tools/memory-model/Documentation/README > b/tools/memory-model/Documentation/README > index 4326603..16177aa 100644 > --- a/tools/memory-model/Documentation/README > +++ b/tools/memory-model/Documentation/README > @@ -8,10 +8,19 @@ number of places. > > This document therefore describes a number of places to start reading > the documentation in this directory, depending on what you know and what > -you would like to learn: > +you would like to learn. These are cumulative, that is, understanding > +of the documents earlier in this list is required by the documents later > +in this list. > > oYou are new to Linux-kernel concurrency: simple.txt > > +oYou have some background in Linux-kernel concurrency, and would > + like an overview of the types of low-level concurrency primitives > + that are provided: ordering.txt > + > + Here, "low level" means atomic operations to single locations in > + memory. > + > oYou are familiar with the concurrency facilities that you > need, and just want to get started with LKMM litmus tests: > litmus-tests.txt > @@ -20,6 +29,9 @@ o You are familiar with Linux-kernel concurrency, and > would > like a detailed intuitive understanding of LKMM, including > situations involving more than two threads: recipes.txt > > +oYou would like a detailed understanding of what your compiler can > + and cannot do to control dependencies: control-dependencies.txt > + > oYou are familiar with Linux-kernel concurrency and the > use of LKMM, and would like a cheat sheet to remind you > of LKMM's guarantees: cheatsheet.txt > @@ -37,12 +49,16 @@ o You are interested in the publications related to LKMM, > including > DESCRIPTION OF FILES > > > -Documentation/README > +README > This file. > > Documentation/cheatsheet.txt > Quick-reference guide to the Linux-kernel memory model. > > +Documentation/control-dependencies.txt > + A guide to preventing compiler optimizations from destroying > + your control dependencies. > + > Documentation/explanation.txt > Describes the memory model in detail. [...]
[PATCH 2/2] Documentation/litmus-tests: Add note on herd7 7.56 in atomic litmus test
>From f808c371075d2f92b955da1a83ecb3828db1972e Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Wed, 24 Jun 2020 06:59:26 +0900
Subject: [PATCH 2/2] Documentation/litmus-tests: Add note on herd7 7.56 in
atomic litmus test
herdtools 7.56 has enhanced herd7's C parser so that the "(void)expr"
construct in Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus is
accepted.
This is independent of LKMM's cat model, so mention the required
version in the header of the litmus test and its entry in README.
CC: Boqun Feng
Reported-by: Andrea Parri
Signed-off-by: Akira Yokosawa
---
Documentation/litmus-tests/README| 1 +
.../atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/litmus-tests/README
b/Documentation/litmus-tests/README
index b79e640214b9..7f5c6c3ed6c3 100644
--- a/Documentation/litmus-tests/README
+++ b/Documentation/litmus-tests/README
@@ -19,6 +19,7 @@ Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus
Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
Test that atomic_set() cannot break the atomicity of atomic RMWs.
+NOTE: Require herd7 7.56 or later which supports "(void)expr".
RCU (/rcu directory)
diff --git
a/Documentation/litmus-tests/atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
b/Documentation/litmus-tests/atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
index 49385314d911..ffd4d3e79c4a 100644
---
a/Documentation/litmus-tests/atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
+++
b/Documentation/litmus-tests/atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
@@ -4,6 +4,7 @@ C Atomic-RMW-ops-are-atomic-WRT-atomic_set
* Result: Never
*
* Test that atomic_set() cannot break the atomicity of atomic RMWs.
+ * NOTE: This requires herd7 7.56 or later which supports "(void)expr".
*)
{
--
2.17.1
[PATCH 1/2] tools/memory-model/README: Mention herdtools7 7.56 in compatibility table
>From 89f96cba0db5643b1d22a0fe740f4c5cac788b29 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Wed, 24 Jun 2020 06:56:43 +0900 Subject: [PATCH 1/2] tools/memory-model/README: Mention herdtools7 7.56 in compatibility table herdtools7 7.56 is going to be released in the week of 22 Jun 2020. Mention the exact version in the compatibility table. Signed-off-by: Akira Yokosawa --- tools/memory-model/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/README b/tools/memory-model/README index 90af203c3cf1..ecb7385376bf 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -54,7 +54,7 @@ klitmus7 Compatibility Table -- 4.18 7.48 -- 4.15 -- 4.19 7.49 -- 4.20 -- 5.5 7.54 -- - 5.6 -- HEAD + 5.6 -- 7.56 -- == -- 2.17.1
Re: [PATCH tip/core/rcu 13/14] tools/memory-model/README: Expand dependency of klitmus7
On Mon, 22 Jun 2020 17:52:30 -0700, paul...@kernel.org wrote:
> From: Akira Yokosawa
>
> klitmus7 is independent of the memory model but depends on the
> build-target kernel release.
> It occasionally lost compatibility due to kernel API changes [1, 2, 3].
> It was remedied in a backwards-compatible manner respectively [4, 5, 6].
>
> Reflect this fact in README.
>
> [1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
> [2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
> [3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
> [4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
> ("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated
> ACCESS_ONCE")
> [5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
> ("klitmus: Avoid variable length array")
> [6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
> ("klitmus: Linux kernel v5.6.x compat")
>
> NOTE: [5] was ahead of herdtools7 7.53, which did not make an
> official release. Code generated by klitmus7 without [5] can still be
> built targeting Linux 4.20--5.5 if you don't care VLA warnings.
>
> Acked-by: Andrea Parri
> Signed-off-by: Akira Yokosawa
> Signed-off-by: Paul E. McKenney
> ---
> tools/memory-model/README | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index b9c562e..90af203 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -28,8 +28,34 @@ downloaded separately:
> See "herdtools7/INSTALL.md" for installation instructions.
>
> Note that although these tools usually provide backwards compatibility,
> -this is not absolutely guaranteed. Therefore, if a later version does
> -not work, please try using the exact version called out above.
> +this is not absolutely guaranteed.
> +
> +For example, a future version of herd7 might not work with the model
> +in this release. A compatible model will likely be made available in
> +a later release of Linux kernel.
> +
> +If you absolutely need to run the model in this particular release,
> +please try using the exact version called out above.
> +
> +klitmus7 is independent of the model provided here. It has its own
> +dependency on a target kernel release where converted code is built
> +and executed. Any change in kernel APIs essential to klitmus7 will
> +necessitate an upgrade of klitmus7.
> +
> +If you find any compatibility issues in klitmus7, please inform the
> +memory model maintainers.
> +
> +klitmus7 Compatibility Table
> +
> +
> + ==
> + target Linux herdtools7
> + --
> + -- 4.18 7.48 --
> + 4.15 -- 4.19 7.49 --
> + 4.20 -- 5.5 7.54 --
> + 5.6 -- HEAD
> + ==
Paul,
I was planning to send an update on this one.
herdtoolds7 7.56 will be released later this week (now tagged 7.56-rc1).
Andrea tested klitmus7 7.56-rc1 against Linux 5.7 and 5.8-rc1.
I tested it against Linux 5.7.4.
klitmus7 worked fine in all these test.
So I think we can safely update the bottom row of the table as:
> + 5.6 -- 7.56 --
Can you amend this one directly?
Or do you want me to send a follow-up patch?
Thanks, Akira
>
>
> ==
>
[RFC PATCH -rcu lkmm] tools/memory-model/README: Expand dependency of klitmus7
>From 87048d7212f6cb16b0a2b85fa6d2f34c28b078c0 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sun, 31 May 2020 20:04:32 +0900
Subject: [PATCH RFC] tools/memory-model/README: Expand dependency of klitmus7
klitmus7 is independent of the memory model but depends on the
build-target kernel release.
It occasionally lost compatibility due to kernel API changes [1, 2, 3].
It was remedied in a backwards-compatible manner respectively [4, 5, 6].
Reflect this fact in README.
[1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
[2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
[3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
[4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated
ACCESS_ONCE")
[5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
("klitmus: Avoid variable length array")
[6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
("klitmus: Linux kernel v5.6.x compat")
NOTE: [5] was ahead of herdtools7 7.53, which did not make an
official release. Code generated by klitmus7 without [5] can still be
built targeting Linux 4.20--5.5 if you don't care VLA warnings.
Signed-off-by: Akira Yokosawa
---
Hi all,
Recent struggle of Andrii with the use of klitmus7 on an up-to-date
Linux system prompted me to add some explanation of klitmus7's dependency
in README.
As herdtools7 7.56 is still under development, I called out just HEAD
in the compatibility table. Once 7.56 is released, the table can be
updated.
I'm not sure if this is the right place to carry such info.
Anyway, I'd be glad if this patch can trigger a meaningful update of
README.
Thanks, Akira
--
tools/memory-model/README | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/tools/memory-model/README b/tools/memory-model/README
index b9c562e92981..90af203c3cf1 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -28,8 +28,34 @@ downloaded separately:
See "herdtools7/INSTALL.md" for installation instructions.
Note that although these tools usually provide backwards compatibility,
-this is not absolutely guaranteed. Therefore, if a later version does
-not work, please try using the exact version called out above.
+this is not absolutely guaranteed.
+
+For example, a future version of herd7 might not work with the model
+in this release. A compatible model will likely be made available in
+a later release of Linux kernel.
+
+If you absolutely need to run the model in this particular release,
+please try using the exact version called out above.
+
+klitmus7 is independent of the model provided here. It has its own
+dependency on a target kernel release where converted code is built
+and executed. Any change in kernel APIs essential to klitmus7 will
+necessitate an upgrade of klitmus7.
+
+If you find any compatibility issues in klitmus7, please inform the
+memory model maintainers.
+
+klitmus7 Compatibility Table
+
+
+ ==
+ target Linux herdtools7
+ --
+-- 4.18 7.48 --
+ 4.15 -- 4.19 7.49 --
+ 4.20 -- 5.5 7.54 --
+ 5.6 -- HEAD
+ ==
==
--
2.17.1
Re: Some -serious- BPF-related litmus tests
On Tue, 26 May 2020 13:19:36 -0700, Andrii Nakryiko wrote: > On Tue, May 26, 2020 at 7:02 AM Akira Yokosawa wrote: >> >> On Tue, 26 May 2020 19:50:47 +0900, Akira Yokosawa wrote: >>> On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote: >>>> On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote: >>>>> >>> [...] >>>>> Yes, that should work. >>>> >>>> Ok, assigning to zero didn't work (it still complained about >>>> uninitialized read), but using a separate int *lenFail to assign to >>>> rLenPtr worked. Curiously, if I used rLenPtr = len1; in error case, it >>>> actually takes a bit more time to verify. >>>> >>>> So I've converted everything else as you suggested. I compiled latest >>>> herd7 and it doesn't produce any warnings. But it's also extremely >>>> slow, compared to the herd7 that I get by default. Validating simple >>>> 1p1c cases takes about 2.5x times longer (0.03s vs 0.07), >> >> Wait a moment! >> >> This 0.03s was the run time of the original 1p1c litmus test, wasn't it? >> Then you are comparing apples and oranges. >> >> How long does your default herd7 take to complete the updated 1p1c test? >> >> Thanks, Akira > > It could be new test vs old test, so I re-ran again. Identical > 1p1c-unbound test: > > OLD version: > > $ herd7 -version && herd7 -unroll 0 -conf linux-kernel.cfg > ../../Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+unbound.litmus > 7.52, Rev: exported > Test bpf-rb+1p1c+unbound Allowed > States 2 > 0:rFail=0; 1:rFail=0; cx=0; len1=1; px=1; > 0:rFail=0; 1:rFail=0; cx=1; len1=1; px=1; > Ok > Witnesses > Positive: 3 Negative: 0 > Condition exists (0:rFail=0 /\ 1:rFail=0 /\ px=1 /\ len1=1 /\ (cx=0 \/ cx=1)) > Observation bpf-rb+1p1c+unbound Always 3 0 > Time bpf-rb+1p1c+unbound 0.03 > Hash=20a68cc69b09fbb79f407f825c015623 > > LATEST from sources version: > > $ herd7 -version && herd7 -unroll 0 -conf linux-kernel.cfg > ../../Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+unbound.litmus > 7.55+01(dev), Rev: 61e23aaee7bba87ccf4cdf1a620a3a9fa8f9a586 > Test bpf-rb+1p1c+unbound Allowed > States 2 > 0:rFail=0; 1:rFail=0; cx=0; len1=1; px=1; > 0:rFail=0; 1:rFail=0; cx=1; len1=1; px=1; > Ok > Witnesses > Positive: 3 Negative: 0 > Condition exists (0:rFail=0 /\ 1:rFail=0 /\ px=1 /\ len1=1 /\ (cx=0 \/ cx=1)) > Observation bpf-rb+1p1c+unbound Always 3 0 > Time bpf-rb+1p1c+unbound 0.06 > Hash=20a68cc69b09fbb79f407f825c015623 > > Still 2x difference. I see opposite tendency on a different set of time consuming litmus tests comparing herd7 7.52 and HEAD. herd7 7.52 herd7 HEAD C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u 8.44 6.12 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u-C 77.19 69.92 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u-CE 355.62 287.27 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u-X 157.87 191.50 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u 2.36 0.94 C-SB+l-o-o-u+l-o-o-u-+l-o-o-u-C 2.32 0.93 C-SB+l-o-o-u+l-o-o-u-+l-o-o-u-CE 5.64 3.52 C-SB+l-o-o-u+l-o-o-u+l-o-o-u-X3.18 2.52 C-SB+l-o-o-u+l-o-o-u+l-o-o-u-XE 11.81 10.35 C-SB+l-o-o-u+l-o-o-u+l-o-o-u 0.25 0.19 C-SB+l-o-o-u+l-o-o-u-C0.15 0.12 C-SB+l-o-o-u+l-o-o-u-CE 0.26 0.20 C-SB+l-o-o-u+l-o-o-u-X0.17 0.14 C-SB+l-o-o-u+l-o-o-u-XE 0.38 0.30 C-SB+l-o-o-u+l-o-o-u 0.04 0.03 NOTE: These were taken on a fairly old PC, with power-saving mode enabled. Did you used the original 1p1c unbound test? I'd like you to compare the updated 1p1c unbound test. Thanks, Akira > >> >>>> but trying >>>> to validate 2p1c case, which normally validates in 42s (unbounded) and >>>> 110s (bounded), it took more than 20 minutes and hasn't finished, >>>> before I gave up. So I don't know what's going on there... >>> >>> herdtools7 has recently been heavily restructured. >>> On the performance regression, I must defer to Luc. >>> >>> Luc, do you have any idea? >>> >>>> >>>> As for klitmus7, I managed to generate everything without warnings, >>>> but couldn't make it build completely due to: >>>> >>>> $
Re: Some -serious- BPF-related litmus tests
On Tue, 26 May 2020 13:15:49 -0700, Andrii Nakryiko wrote:
> On Tue, May 26, 2020 at 3:50 AM Akira Yokosawa wrote:
>>
>> On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote:
>>> On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
>>>>
>> [...]
>>>> Yes, that should work.
>>>
>>> Ok, assigning to zero didn't work (it still complained about
>>> uninitialized read), but using a separate int *lenFail to assign to
>>> rLenPtr worked. Curiously, if I used rLenPtr = len1; in error case, it
>>> actually takes a bit more time to verify.
>>>
>>> So I've converted everything else as you suggested. I compiled latest
>>> herd7 and it doesn't produce any warnings. But it's also extremely
>>> slow, compared to the herd7 that I get by default. Validating simple
>>> 1p1c cases takes about 2.5x times longer (0.03s vs 0.07), but trying
>>> to validate 2p1c case, which normally validates in 42s (unbounded) and
>>> 110s (bounded), it took more than 20 minutes and hasn't finished,
>>> before I gave up. So I don't know what's going on there...
>>
>> herdtools7 has recently been heavily restructured.
>> On the performance regression, I must defer to Luc.
>>
>> Luc, do you have any idea?
>>
>>>
>>> As for klitmus7, I managed to generate everything without warnings,
>>> but couldn't make it build completely due to:
>>>
>>> $ make
>>> make -C /lib/modules/5.6.13-01802-g938d64da97c6/build/
>>
>> So you are on Linux 5.6.x which requires cutting-edge klitmus7.
>>
>
> Right, so I retried with the klitmus7 built from sources:
>
> $ klitmus7 -version
>
> 7.55+01(dev)
>
> Still can't compile, though task_struct problem went away, proc_ops
> error is still present:
>
> $ make
> grep:
> /lib/modules/5.7.0-rc5-02014-gb16540c748e9/build/include/linux/proc_fs.h:
> No such file or directory
Hmm, have you installed kernel-headers on your system?
You are now on Linux 5.7-rc5 based system...
Thanks, Akira
> make -C /lib/modules/5.7.0-rc5-02014-gb16540c748e9/build/
> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules
> make[1]: Entering directory `/data/users/andriin/linux-build/fb-config'
> make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64'
> grep:
> /lib/modules/5.7.0-rc5-02014-gb16540c748e9/build/include/linux/proc_fs.h:
> No such file or directory
> CC [M]
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
> In function ‘litmus_init’:
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:621:67:
> error: passing argument 4 of ‘proc_create’ from incompatible pointer
> type [-Werror=incompatible-pointer-types]
>struct proc_dir_entry *litmus_pde =
> proc_create("litmus",0,NULL,_proc_ops);
>
> ^~~~
> In file included from
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:15:
> /data/users/andriin/linux/include/linux/proc_fs.h:79:24: note:
> expected ‘const struct proc_ops *’ but argument is of type ‘const
> struct file_operations *’
> struct proc_dir_entry *proc_create(const char *name, umode_t mode,
> struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
> ^~~
> cc1: some warnings being treated as errors
> make[3]: ***
> [/home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o]
> Error 1
> make[2]: *** [/home/andriin/local/linux-trees/tools/memory-model/mymodules]
> Error 2
> make[2]: Leaving directory `/data/users/andriin/linux-build/default-x86_64'
> make[1]: *** [sub-make] Error 2
> make[1]: Leaving directory `/data/users/andriin/linux-build/fb-config'
> make: *** [all] Error 2
>
> Don't know if I'm missing some headers or whatever.
>
>>> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules
>>> make[1]: Entering directory `/data/users/andriin/linux-build/fb-config'
>>> make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64'
>>> CC [M]
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
>>> In function ‘zyva’:
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:507:12:
>>> warning: ISO C90 forbids variable length array ‘th’ [-Wvla]
>>> struct task_struct *th[nth];
>>> ^~~
>>&g
Re: Some -serious- BPF-related litmus tests
On Tue, 26 May 2020 19:50:47 +0900, Akira Yokosawa wrote:
> On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote:
>> On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
>>>
> [...]
>>> Yes, that should work.
>>
>> Ok, assigning to zero didn't work (it still complained about
>> uninitialized read), but using a separate int *lenFail to assign to
>> rLenPtr worked. Curiously, if I used rLenPtr = len1; in error case, it
>> actually takes a bit more time to verify.
>>
>> So I've converted everything else as you suggested. I compiled latest
>> herd7 and it doesn't produce any warnings. But it's also extremely
>> slow, compared to the herd7 that I get by default. Validating simple
>> 1p1c cases takes about 2.5x times longer (0.03s vs 0.07),
Wait a moment!
This 0.03s was the run time of the original 1p1c litmus test, wasn't it?
Then you are comparing apples and oranges.
How long does your default herd7 take to complete the updated 1p1c test?
Thanks, Akira
>> but trying
>> to validate 2p1c case, which normally validates in 42s (unbounded) and
>> 110s (bounded), it took more than 20 minutes and hasn't finished,
>> before I gave up. So I don't know what's going on there...
>
> herdtools7 has recently been heavily restructured.
> On the performance regression, I must defer to Luc.
>
> Luc, do you have any idea?
>
>>
>> As for klitmus7, I managed to generate everything without warnings,
>> but couldn't make it build completely due to:
>>
>> $ make
>> make -C /lib/modules/5.6.13-01802-g938d64da97c6/build/
>
> So you are on Linux 5.6.x which requires cutting-edge klitmus7.
>
>> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules
>> make[1]: Entering directory `/data/users/andriin/linux-build/fb-config'
>> make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64'
>> CC [M]
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
>> In function ‘zyva’:
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:507:12:
>> warning: ISO C90 forbids variable length array ‘th’ [-Wvla]
>> struct task_struct *th[nth];
>> ^~~
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
>> In function ‘litmus_init’:
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:605:67:
>> error: passing argument 4 of ‘proc_create’ from incompatible pointer
>> type [-Werror=incompatible-pointer-types]
>>struct proc_dir_entry *litmus_pde =
>> proc_create("litmus",0,NULL,_proc_fops);
>>
>> ^
>> In file included from
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:15:
>> /data/users/andriin/linux-fb/include/linux/proc_fs.h:64:24: note:
>> expected ‘const struct proc_ops *’ but argument is of type ‘const
>> struct file_operations *’
>> struct proc_dir_entry *proc_create(const char *name, umode_t mode,
>> struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
>> ^~~
>> cc1: some warnings being treated as errors
>> make[3]: ***
>> [/home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o]
>> Error 1
>> make[2]: *** [/home/andriin/local/linux-trees/tools/memory-model/mymodules]
>> Error 2
>> make[2]: Leaving directory `/data/users/andriin/linux-build/default-x86_64'
>> make[1]: *** [sub-make] Error 2
>> make[1]: Leaving directory `/data/users/andriin/linux-build/fb-config'
>> make: *** [all] Error 2
>>
>
> These errors suggest the klitmus7 you used is version 7.52 or some such.
> You said you have built herd7 from the source. Have you also built klitmus7?
>
> The up-to-date klitmus7 should generate code compatible with Linux 5.6.x.
>
> Could you try with the latest one?
>
> Thanks, Akira
>
>>
>> But at least it doesn't complain about atomic_t anymore. So anyways,
>> I'm going to post updated litmus tests separately from BPF ringbuf
>> patches, because Documentation/litmus-tests is not yet present in
>> bpf-next.
>>
>>>
>>> You can find a basic introduction of klitmus7 in tools/memory-model/README.
>>>
>>> Thanks, Akira
>>>
>>>>
>>>>>
>>>>> Please note that if you are on Linux 5.6 (or later), you need an
>>>>> up-to-date
>>>>> klitmus7 due to a change in kernel API.
>>>>>
>>>>> Any question is welcome!
>>>>>
>>>>> Thanks, Akira
>>>>>
>>
>> [...]
>>
>
Re: Some -serious- BPF-related litmus tests
On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote:
> On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
>>
[...]
>> Yes, that should work.
>
> Ok, assigning to zero didn't work (it still complained about
> uninitialized read), but using a separate int *lenFail to assign to
> rLenPtr worked. Curiously, if I used rLenPtr = len1; in error case, it
> actually takes a bit more time to verify.
>
> So I've converted everything else as you suggested. I compiled latest
> herd7 and it doesn't produce any warnings. But it's also extremely
> slow, compared to the herd7 that I get by default. Validating simple
> 1p1c cases takes about 2.5x times longer (0.03s vs 0.07), but trying
> to validate 2p1c case, which normally validates in 42s (unbounded) and
> 110s (bounded), it took more than 20 minutes and hasn't finished,
> before I gave up. So I don't know what's going on there...
herdtools7 has recently been heavily restructured.
On the performance regression, I must defer to Luc.
Luc, do you have any idea?
>
> As for klitmus7, I managed to generate everything without warnings,
> but couldn't make it build completely due to:
>
> $ make
> make -C /lib/modules/5.6.13-01802-g938d64da97c6/build/
So you are on Linux 5.6.x which requires cutting-edge klitmus7.
> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules
> make[1]: Entering directory `/data/users/andriin/linux-build/fb-config'
> make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64'
> CC [M]
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
> In function ‘zyva’:
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:507:12:
> warning: ISO C90 forbids variable length array ‘th’ [-Wvla]
> struct task_struct *th[nth];
> ^~~
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
> In function ‘litmus_init’:
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:605:67:
> error: passing argument 4 of ‘proc_create’ from incompatible pointer
> type [-Werror=incompatible-pointer-types]
>struct proc_dir_entry *litmus_pde =
> proc_create("litmus",0,NULL,_proc_fops);
>
> ^
> In file included from
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:15:
> /data/users/andriin/linux-fb/include/linux/proc_fs.h:64:24: note:
> expected ‘const struct proc_ops *’ but argument is of type ‘const
> struct file_operations *’
> struct proc_dir_entry *proc_create(const char *name, umode_t mode,
> struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
> ^~~
> cc1: some warnings being treated as errors
> make[3]: ***
> [/home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o]
> Error 1
> make[2]: *** [/home/andriin/local/linux-trees/tools/memory-model/mymodules]
> Error 2
> make[2]: Leaving directory `/data/users/andriin/linux-build/default-x86_64'
> make[1]: *** [sub-make] Error 2
> make[1]: Leaving directory `/data/users/andriin/linux-build/fb-config'
> make: *** [all] Error 2
>
These errors suggest the klitmus7 you used is version 7.52 or some such.
You said you have built herd7 from the source. Have you also built klitmus7?
The up-to-date klitmus7 should generate code compatible with Linux 5.6.x.
Could you try with the latest one?
Thanks, Akira
>
> But at least it doesn't complain about atomic_t anymore. So anyways,
> I'm going to post updated litmus tests separately from BPF ringbuf
> patches, because Documentation/litmus-tests is not yet present in
> bpf-next.
>
>>
>> You can find a basic introduction of klitmus7 in tools/memory-model/README.
>>
>> Thanks, Akira
>>
>>>
>>>>
>>>> Please note that if you are on Linux 5.6 (or later), you need an up-to-date
>>>> klitmus7 due to a change in kernel API.
>>>>
>>>> Any question is welcome!
>>>>
>>>> Thanks, Akira
>>>>
>
> [...]
>
Re: Some -serious- BPF-related litmus tests
On Mon, 25 May 2020 11:31:27 -0700, Andrii Nakryiko wrote: > On Sun, May 24, 2020 at 5:09 AM Akira Yokosawa wrote: >> >> On Fri, 22 May 2020 12:38:21 -0700, Andrii Nakryiko wrote: >>> On 5/22/20 10:43 AM, Paul E. McKenney wrote: >>>> On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote: >>>>> On Fri, May 22, 2020 at 11:44:07AM +0200, Peter Zijlstra wrote: >>>>>> On Thu, May 21, 2020 at 05:38:50PM -0700, Paul E. McKenney wrote: >>>>>>> Hello! >>>>>>> >>>>>>> Just wanted to call your attention to some pretty cool and pretty >>>>>>> serious >>>>>>> litmus tests that Andrii did as part of his BPF ring-buffer work: >>>>>>> >>>>>>> https://lore.kernel.org/bpf/20200517195727.279322-3-andr...@fb.com/ >>>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> I find: >>>>>> >>>>>> smp_wmb() >>>>>> smp_store_release() >>>>>> >>>>>> a _very_ weird construct. What is that supposed to even do? >>>>> >>>>> Indeed, it looks like one or the other of those is redundant (depending >>>>> on the context). >>>> >>>> Probably. Peter instead asked what it was supposed to even do. ;-) >>> >>> I agree, I think smp_wmb() is redundant here. Can't remember why I thought >>> that it's necessary, this algorithm went through a bunch of iterations, >>> starting as completely lockless, also using READ_ONCE/WRITE_ONCE at some >>> point, and settling on smp_read_acquire/smp_store_release, eventually. >>> Maybe there was some reason, but might be that I was just over-cautious. >>> See reply on patch thread as well ([0]). >>> >>> [0] >>> https://lore.kernel.org/bpf/caef4bza26abrmtwcod5+tfhnmnu6p5yj8zo+soajcdtp1jv...@mail.gmail.com/ >>> >>> >>>> >>>>> Also, what use is a spinlock that is accessed in only one thread? >>>> >>>> Multiple writers synchronize via the spinlock in this case. I am >>>> guessing that his larger 16-hour test contended this spinlock. >>> >>> Yes, spinlock is for coordinating multiple producers. 2p1c cases (bounded >>> and unbounded) rely on this already. 1p1c cases are sort of subsets (but >>> very fast to verify) checking only consumer/producer interaction. >>> >>>> >>>>> Finally, I doubt that these tests belong under tools/memory-model. >>>>> Shouldn't they go under the new Documentation/ directory for litmus >>>>> tests? And shouldn't the patch update a README file? >>>> >>>> Agreed, and I responded to that effect to his original patch: >>>> >>>> https://lore.kernel.org/bpf/20200522003433.GG2869@paulmck-ThinkPad-P72/ >>> >>> Yep, makes sense, I'll will move. >> >> Hi Andrii, >> >> Andrea reported off-the-list that your litmus tests are incompatible >> with the to-be-released version 7.56 of herd7 and currently available >> versions of klitmus7. >> >> This is due to a couple of C-language level issues. >> >> herd7 used to be fairly generous in parsing C litmus tests. >> On the other hand, klitmus7 converts a litmus test into a >> kernel module. The converted code is built by an actual C compiler >> with kernel headers included, and can fail to build due to syntax errors >> or serious warnings. >> herd7 HEAD is getting slightly stricter on uninitialized variable and >> it emits an error to mpsc-rb+1p1c+bounded.litmus: >> >> Warning: File "mpsc-rb+1p1c+bounded.litmus": read on location 0 does not >> match any write >> >> Converted code by klitmus7 fails to build with the following warning >> messages: >> >> $ make >> make -C /lib/modules/5.3.0-53-generic/build/ M=/home/akira/bpf-rb/klitmus >> modules >> make[1]: Entering directory '/usr/src/linux-headers-5.3.0-53-generic' >> CC [M] /home/akira/bpf-rb/klitmus/litmus000.o >> /home/akira/bpf-rb/klitmus/litmus000.c: In function ‘code1’: >> /home/akira/bpf-rb/klitmus/litmus000.c:426:14: error: passing argument 1 of >> ‘atomic_inc’ >> from incompatible pointer type [-Werror=incompatible-pointer-types] >>atomic_inc(dropped); >> ^~~ >> In file included from ./arch/x86/include/asm/atomic.h:265:0, >> from ./arc
Re: Some -serious- BPF-related litmus tests
On Fri, 22 May 2020 12:38:21 -0700, Andrii Nakryiko wrote:
> On 5/22/20 10:43 AM, Paul E. McKenney wrote:
>> On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote:
>>> On Fri, May 22, 2020 at 11:44:07AM +0200, Peter Zijlstra wrote:
On Thu, May 21, 2020 at 05:38:50PM -0700, Paul E. McKenney wrote:
> Hello!
>
> Just wanted to call your attention to some pretty cool and pretty serious
> litmus tests that Andrii did as part of his BPF ring-buffer work:
>
> https://lore.kernel.org/bpf/20200517195727.279322-3-andr...@fb.com/
>
> Thoughts?
I find:
smp_wmb()
smp_store_release()
a _very_ weird construct. What is that supposed to even do?
>>>
>>> Indeed, it looks like one or the other of those is redundant (depending
>>> on the context).
>>
>> Probably. Peter instead asked what it was supposed to even do. ;-)
>
> I agree, I think smp_wmb() is redundant here. Can't remember why I thought
> that it's necessary, this algorithm went through a bunch of iterations,
> starting as completely lockless, also using READ_ONCE/WRITE_ONCE at some
> point, and settling on smp_read_acquire/smp_store_release, eventually. Maybe
> there was some reason, but might be that I was just over-cautious. See reply
> on patch thread as well ([0]).
>
> Â [0]
> https://lore.kernel.org/bpf/caef4bza26abrmtwcod5+tfhnmnu6p5yj8zo+soajcdtp1jv...@mail.gmail.com/
>
>
>>
>>> Also, what use is a spinlock that is accessed in only one thread?
>>
>> Multiple writers synchronize via the spinlock in this case. I am
>> guessing that his larger 16-hour test contended this spinlock.
>
> Yes, spinlock is for coordinating multiple producers. 2p1c cases (bounded and
> unbounded) rely on this already. 1p1c cases are sort of subsets (but very
> fast to verify) checking only consumer/producer interaction.
>
>>
>>> Finally, I doubt that these tests belong under tools/memory-model.
>>> Shouldn't they go under the new Documentation/ directory for litmus
>>> tests? And shouldn't the patch update a README file?
>>
>> Agreed, and I responded to that effect to his original patch:
>>
>> https://lore.kernel.org/bpf/20200522003433.GG2869@paulmck-ThinkPad-P72/
>
> Yep, makes sense, I'll will move.
Hi Andrii,
Andrea reported off-the-list that your litmus tests are incompatible
with the to-be-released version 7.56 of herd7 and currently available
versions of klitmus7.
This is due to a couple of C-language level issues.
herd7 used to be fairly generous in parsing C litmus tests.
On the other hand, klitmus7 converts a litmus test into a
kernel module. The converted code is built by an actual C compiler
with kernel headers included, and can fail to build due to syntax errors
or serious warnings.
herd7 HEAD is getting slightly stricter on uninitialized variable and
it emits an error to mpsc-rb+1p1c+bounded.litmus:
Warning: File "mpsc-rb+1p1c+bounded.litmus": read on location 0 does not match
any write
Converted code by klitmus7 fails to build with the following warning messages:
$ make
make -C /lib/modules/5.3.0-53-generic/build/ M=/home/akira/bpf-rb/klitmus
modules
make[1]: Entering directory '/usr/src/linux-headers-5.3.0-53-generic'
CC [M] /home/akira/bpf-rb/klitmus/litmus000.o
/home/akira/bpf-rb/klitmus/litmus000.c: In function ‘code1’:
/home/akira/bpf-rb/klitmus/litmus000.c:426:14: error: passing argument 1 of
‘atomic_inc’
from incompatible pointer type [-Werror=incompatible-pointer-types]
atomic_inc(dropped);
^~~
In file included from ./arch/x86/include/asm/atomic.h:265:0,
from ./arch/x86/include/asm/msr.h:67,
from ./arch/x86/include/asm/processor.h:21,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:38,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:78,
from ./include/linux/spinlock.h:51,
from ./include/linux/seqlock.h:36,
from ./include/linux/time.h:6,
from ./include/linux/stat.h:19,
from ./include/linux/module.h:10,
from /home/akira/bpf-rb/klitmus/litmus000.c:11:
./include/asm-generic/atomic-instrumented.h:237:1: note: expected ‘atomic_t *
{aka struct *}’ but argument is of type ‘int *’
atomic_inc(atomic_t *v)
^~
In file included from ./include/linux/export.h:45:0,
from ./include/linux/linkage.h:7,
from ./include/linux/kernel.h:8,
from ./include/linux/list.h:9,
from ./include/linux/module.h:9,
from /home/akira/bpf-rb/klitmus/litmus000.c:11:
/home/akira/bpf-rb/klitmus/litmus000.c: In function ‘thread0’:
./include/linux/compiler.h:187:26: warning: ‘rLenPtr’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
Re: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's README into top-level one
On Thu, 14 May 2020 15:45:58 -0700, Paul E. McKenney wrote:
> On Fri, May 15, 2020 at 07:03:33AM +0900, Akira Yokosawa wrote:
>> On Thu, 14 May 2020 10:16:56 -0700, Paul E. McKenney wrote:
>>> On Thu, May 14, 2020 at 08:46:18AM +0800, Boqun Feng wrote:
>>>> On Wed, May 13, 2020 at 06:39:03AM +0900, Akira Yokosawa wrote:
>>>>> From 96fa6680e3b990633ecbb6d11acf03a161b790bd Mon Sep 17 00:00:00 2001
>>>>> From: Akira Yokosawa
>>>>> Date: Sun, 10 May 2020 15:12:57 +0900
>>>>> Subject: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's
>>>>> README into top-level one
>>>>>
>>>>> Where Documentation/litmus-tests/README lists RCU litmus tests,
>>>>> Documentation/litmus-tests/atomic/README lists atomic litmus tests.
>>>>> For symmetry, merge the latter into former, with some context
>>>>> adjustment in the introduction.
>>>>>
>>>>> Signed-off-by: Akira Yokosawa
>>>>> Acked-by: Andrea Parri
>>>>> Acked-by: Joel Fernandes (Google)
>>>>
>>>> Acked-by: Boqun Feng
>>>>
>>>> Thanks!
>>>
>>> Applied, and thank you all!
>>>
>>> I rebased, cancelling the revert with the original, resulting in an
>>> updated lkmm branch on -rcu. There was one minor conflict, so could
>>> one of you please check to make sure that I resolved things appropriately?
>>
>> One thing I noticed.
>>
>> Commit b2998782ded4 ("Documentation/litmus-tests: Clarify about the RCU
>> pre-initialization test")'s change log says:
>>
>> Since this test returned to tools/memory-model/, make sure that it is
>> ~~~
>> at least referenced from Documentation/litmus-tests/'s README.
>>
>> Because of the rebase, this needs amendment as well as the title.
>>
>> Something like
>>
>> Documentation/litumus-tests: Cite a relevant litmus test in
>> tools/memory-model
>>
>> For ease of finding the RCU related litmus test under
>> tools/memory-model/, add an entry in README.
>>
>> ?
>
> Good catch, and yes, I will update that on the next rebase.
>
> Any other things in need of adjustment?
Aside from the missing Signed-off-by tags Stephen pointed out, I don't
see anything.
Thanks, Akira
>
> Thanx, Paul
Re: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's README into top-level one
On Thu, 14 May 2020 10:16:56 -0700, Paul E. McKenney wrote:
> On Thu, May 14, 2020 at 08:46:18AM +0800, Boqun Feng wrote:
>> On Wed, May 13, 2020 at 06:39:03AM +0900, Akira Yokosawa wrote:
>>> From 96fa6680e3b990633ecbb6d11acf03a161b790bd Mon Sep 17 00:00:00 2001
>>> From: Akira Yokosawa
>>> Date: Sun, 10 May 2020 15:12:57 +0900
>>> Subject: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's
>>> README into top-level one
>>>
>>> Where Documentation/litmus-tests/README lists RCU litmus tests,
>>> Documentation/litmus-tests/atomic/README lists atomic litmus tests.
>>> For symmetry, merge the latter into former, with some context
>>> adjustment in the introduction.
>>>
>>> Signed-off-by: Akira Yokosawa
>>> Acked-by: Andrea Parri
>>> Acked-by: Joel Fernandes (Google)
>>
>> Acked-by: Boqun Feng
>>
>> Thanks!
>
> Applied, and thank you all!
>
> I rebased, cancelling the revert with the original, resulting in an
> updated lkmm branch on -rcu. There was one minor conflict, so could
> one of you please check to make sure that I resolved things appropriately?
One thing I noticed.
Commit b2998782ded4 ("Documentation/litmus-tests: Clarify about the RCU
pre-initialization test")'s change log says:
Since this test returned to tools/memory-model/, make sure that it is
~~~
at least referenced from Documentation/litmus-tests/'s README.
Because of the rebase, this needs amendment as well as the title.
Something like
Documentation/litumus-tests: Cite a relevant litmus test in
tools/memory-model
For ease of finding the RCU related litmus test under
tools/memory-model/, add an entry in README.
?
Thanks, Akira
>
> Thanx, Paul
>
>> Regards,
>> Boqun
>>
>>> ---
>>> Documentation/litmus-tests/README| 19 +++
>>> Documentation/litmus-tests/atomic/README | 16
>>> 2 files changed, 19 insertions(+), 16 deletions(-)
>>> delete mode 100644 Documentation/litmus-tests/atomic/README
>>>
>>> diff --git a/Documentation/litmus-tests/README
>>> b/Documentation/litmus-tests/README
>>> index c4307ea9f996..ac0b270b456c 100644
>>> --- a/Documentation/litmus-tests/README
>>> +++ b/Documentation/litmus-tests/README
>>> @@ -2,6 +2,25 @@
>>> LITMUS TESTS
>>>
>>>
>>> +Each subdirectory contains litmus tests that are typical to describe the
>>> +semantics of respective kernel APIs.
>>> +For more information about how to "run" a litmus test or how to generate
>>> +a kernel test module based on a litmus test, please see
>>> +tools/memory-model/README.
>>> +
>>> +
>>> +atomic (/atomic derectory)
>>> +--
>>> +
>>> +Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus
>>> +Test that an atomic RMW followed by a smp_mb__after_atomic() is
>>> +stronger than a normal acquire: both the read and write parts of
>>> +the RMW are ordered before the subsequential memory accesses.
>>> +
>>> +Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
>>> +Test that atomic_set() cannot break the atomicity of atomic RMWs.
>>> +
>>> +
>>> RCU (/rcu directory)
>>>
>>>
>>> diff --git a/Documentation/litmus-tests/atomic/README
>>> b/Documentation/litmus-tests/atomic/README
>>> deleted file mode 100644
>>> index 714cf93816ea..
>>> --- a/Documentation/litmus-tests/atomic/README
>>> +++ /dev/null
>>> @@ -1,16 +0,0 @@
>>> -This directory contains litmus tests that are typical to describe the
>>> semantics
>>> -of our atomic APIs. For more information about how to "run" a litmus test
>>> or
>>> -how to generate a kernel test module based on a litmus test, please see
>>> -tools/memory-model/README.
>>> -
>>> -
>>> -LITMUS TESTS
>>> -
>>> -
>>> -Atomic-RMW+mb__after_atomic-is-stronger-than-acquire
>>> - Test that an atomic RMW followed by a smp_mb__after_atomic() is
>>> - stronger than a normal acquire: both the read and write parts of
>>> - the RMW are ordered before the subsequential memory accesses.
>>> -
>>> -Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
>>> - Test that atomic_set() cannot break the atomicity of atomic RMWs.
>>> --
>>> 2.17.1
>>>
>>>
Re: [PATCH 4/3] docs: litmus-tests: Clarify about the RCU pre-initialization test
On Tue, 12 May 2020 17:43:42 -0400, Joel Fernandes wrote:
> On Tue, May 12, 2020 at 09:30:22AM -0700, Paul E. McKenney wrote:
>> On Tue, May 12, 2020 at 11:41:01AM -0400, Joel Fernandes wrote:
>>> On Tue, May 12, 2020 at 11:07 AM Akira Yokosawa wrote:
>>>>
>>>> From 7bb979aacd8788d174df8a56e9803ba9e5b7a381 Mon Sep 17 00:00:00 2001
>>>> From: Joel Fernandes (Google)
>>>> Date: Mon, 11 May 2020 22:06:46 -0400
>>>> Subject: [PATCH 4/3] docs: litmus-tests: Clarify about the RCU
>>>> pre-initialization test
>>>>
>>>> Since this test returned to tools/memory-model/, make sure that it is
>>>> at least referenced from Documentation/litmus-tests/'s README.
>>>>
>>>> Co-developed-by: Joel Fernandes (Google)
>>>> Co-developed-by: Akira Yokosawa
>>>> [Alan: grammar nit]
>>>> Suggested-by: Alan Stern
>>>> Signed-off-by: Joel Fernandes (Google)
>>>> Signed-off-by: Akira Yokosawa
>>>> ---
>>>> I said in the earlier message:
>>>>
>>>>> The explanation under tools/memory-model/litmus-tests/README also need
>>>>> the same
>>>>> rewording.
>>>>
>>>> , but obviously I was confused. It is good as is.
>>>>
>>>> This is on top of my earlier patch series.
>>>>
>>>> Joel, Alan, does this work with you?
>>>
>>> Yes, thanks a lot for doing it. Paul are you Ok with it too?
>>
>> Looks good to me!
>>
>> Could one of you please send a patch series and instructions, which I
>> -think- will be of the form:
>>
>> oRevert a5cca3485d92 ("Documentation: LKMM: Move
>> MP+onceassign+derefonce to new litmus-tests/rcu/")
>>
>> oApply a series of patches.
>
> Rebased Akira's 3 and my 1 on top of your /dev branch with the ordering done
> as above:
Oh, I missed the reordering part in my PATCH RESEND series.
Paul, it's up to you which you pull/apply.
Thanks, Akira
>
> Could you pull?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (branch
> for-paul-dev)
>
> Thanks!
>
> - Joel
>
[PATCH RESEND 4/4] docs: litmus-tests: Clarify about the RCU pre-initialization test
>From c2d6a0afad370c6fda136704bac9b1ee9557d0eb Mon Sep 17 00:00:00 2001 From: "Joel Fernandes (Google)" Date: Mon, 11 May 2020 22:06:46 -0400 Subject: [PATCH RESEND 4/4] docs: litmus-tests: Clarify about the RCU pre-initialization test Since this test returned to tools/memory-model/, make sure that it is at least referenced from Documentation/litmus-tests/'s README. Co-developed-by: Joel Fernandes (Google) Co-developed-by: Akira Yokosawa [Alan: grammar nit] Suggested-by: Alan Stern Signed-off-by: Joel Fernandes (Google) Signed-off-by: Akira Yokosawa --- Documentation/litmus-tests/README | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index ac0b270b456c..b79e640214b9 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -24,6 +24,10 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus RCU (/rcu directory) +MP+onceassign+derefonce.litmus (under tools/memory-model/litmus-tests/) +Demonstrates the use of rcu_assign_pointer() and rcu_dereference() to +ensure that an RCU reader will not see pre-initialization garbage. + RCU+sync+read.litmus RCU+sync+free.litmus Both the above litmus tests demonstrate the RCU grace period guarantee -- 2.17.1
[PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's README into top-level one
>From 96fa6680e3b990633ecbb6d11acf03a161b790bd Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Sun, 10 May 2020 15:12:57 +0900 Subject: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's README into top-level one Where Documentation/litmus-tests/README lists RCU litmus tests, Documentation/litmus-tests/atomic/README lists atomic litmus tests. For symmetry, merge the latter into former, with some context adjustment in the introduction. Signed-off-by: Akira Yokosawa Acked-by: Andrea Parri Acked-by: Joel Fernandes (Google) --- Documentation/litmus-tests/README| 19 +++ Documentation/litmus-tests/atomic/README | 16 2 files changed, 19 insertions(+), 16 deletions(-) delete mode 100644 Documentation/litmus-tests/atomic/README diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index c4307ea9f996..ac0b270b456c 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -2,6 +2,25 @@ LITMUS TESTS +Each subdirectory contains litmus tests that are typical to describe the +semantics of respective kernel APIs. +For more information about how to "run" a litmus test or how to generate +a kernel test module based on a litmus test, please see +tools/memory-model/README. + + +atomic (/atomic derectory) +-- + +Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus +Test that an atomic RMW followed by a smp_mb__after_atomic() is +stronger than a normal acquire: both the read and write parts of +the RMW are ordered before the subsequential memory accesses. + +Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus +Test that atomic_set() cannot break the atomicity of atomic RMWs. + + RCU (/rcu directory) diff --git a/Documentation/litmus-tests/atomic/README b/Documentation/litmus-tests/atomic/README deleted file mode 100644 index 714cf93816ea.. --- a/Documentation/litmus-tests/atomic/README +++ /dev/null @@ -1,16 +0,0 @@ -This directory contains litmus tests that are typical to describe the semantics -of our atomic APIs. For more information about how to "run" a litmus test or -how to generate a kernel test module based on a litmus test, please see -tools/memory-model/README. - - -LITMUS TESTS - - -Atomic-RMW+mb__after_atomic-is-stronger-than-acquire - Test that an atomic RMW followed by a smp_mb__after_atomic() is - stronger than a normal acquire: both the read and write parts of - the RMW are ordered before the subsequential memory accesses. - -Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus - Test that atomic_set() cannot break the atomicity of atomic RMWs. -- 2.17.1
[PATCH RESEND 2/4] Revert "Documentation: LKMM: Move MP+onceassign+derefonce to new litmus-tests/rcu/"
>From dec86a9f1a947ae01d8b66b4f5d9b431fb2a55b5 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sun, 10 May 2020 13:43:34 +0900
Subject: [PATCH RESEND 2/4] Revert "Documentation: LKMM: Move
MP+onceassign+derefonce to new litmus-tests/rcu/"
This reverts commit a5cca3485d9206a9dbbc6f47d2a537e69b53cd82.
MP+onceassign+derefonce.litmus is called out from
tools/memory-model/Documentation/recipes.txt.
It should be in the same directory as the other representative tests
to help readers inspect it.
Signed-off-by: Akira Yokosawa
Acked-by: Andrea Parri
Acked-by: Joel Fernandes (Google)
---
Documentation/litmus-tests/README | 3 ---
.../memory-model/litmus-tests}/MP+onceassign+derefonce.litmus | 0
tools/memory-model/litmus-tests/README | 3 +++
3 files changed, 3 insertions(+), 3 deletions(-)
rename {Documentation/litmus-tests/rcu =>
tools/memory-model/litmus-tests}/MP+onceassign+derefonce.litmus (100%)
diff --git a/Documentation/litmus-tests/README
b/Documentation/litmus-tests/README
index 79d187f75679..c4307ea9f996 100644
--- a/Documentation/litmus-tests/README
+++ b/Documentation/litmus-tests/README
@@ -4,9 +4,6 @@ LITMUS TESTS
RCU (/rcu directory)
-MP+onceassign+derefonce.litmus
-Demonstrates that rcu_assign_pointer() and rcu_dereference() to
-ensure that an RCU reader will not see pre-initialization garbage.
RCU+sync+read.litmus
RCU+sync+free.litmus
diff --git a/Documentation/litmus-tests/rcu/MP+onceassign+derefonce.litmus
b/tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus
similarity index 100%
rename from Documentation/litmus-tests/rcu/MP+onceassign+derefonce.litmus
rename to tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus
diff --git a/tools/memory-model/litmus-tests/README
b/tools/memory-model/litmus-tests/README
index 79e1b1ed4929..681f9067fa9e 100644
--- a/tools/memory-model/litmus-tests/README
+++ b/tools/memory-model/litmus-tests/README
@@ -63,6 +63,9 @@ LB+poonceonces.litmus
As above, but with store-release replaced with WRITE_ONCE()
and load-acquire replaced with READ_ONCE().
+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
--
2.17.1
[PATCH RESEND 1/4] tools/memory-model: Fix reference to litmus test in recipes.txt
>From f9aa6cde74b95cdaae67d484504c3dd69e8bc205 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sun, 10 May 2020 13:37:14 +0900
Subject: [PATCH RESEND 1/4] tools/memory-model: Fix reference to litmus test in
recipes.txt
The name of litmus test doesn't match the one described below.
Fix the name of litmus test.
Signed-off-by: Akira Yokosawa
Acked-by: Andrea Parri
Acked-by: Joel Fernandes (Google)
---
tools/memory-model/Documentation/recipes.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/memory-model/Documentation/recipes.txt
b/tools/memory-model/Documentation/recipes.txt
index 7fe8d7aa3029..63c4adfed884 100644
--- a/tools/memory-model/Documentation/recipes.txt
+++ b/tools/memory-model/Documentation/recipes.txt
@@ -126,7 +126,7 @@ However, it is not necessarily the case that accesses
ordered by
locking will be seen as ordered by CPUs not holding that lock.
Consider this example:
- /* See Z6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus. */
+ /* See Z6.0+pooncelock+pooncelock+pombonce.litmus. */
void CPU0(void)
{
spin_lock();
--
2.17.1
[PATCH RESEND 0/4] tools/memory-model, Documentation/litmus-test: Sort out, location of litmus test and README
Hi Paul,
On Tue, 12 May 2020 09:30:22 -0700, Paul E. McKenney wrote:
> Could one of you please send a patch series and instructions, which I
> -think- will be of the form:
>
> o Revert a5cca3485d92 ("Documentation: LKMM: Move
> MP+onceassign+derefonce to new litmus-tests/rcu/")
>
> o Apply a series of patches.
Here you are!
Note: For 1/4 -- 3/4, Added Andrea's and Joel's Acked-by tags.
Thanks, Akira
--
Akira Yokosawa (3):
tools/memory-model: Fix reference to litmus test in recipes.txt
Revert "Documentation: LKMM: Move MP+onceassign+derefonce to new
litmus-tests/rcu/"
Documentation/litmus-tests: Merge atomic's README into top-level one
Joel Fernandes (Google) (1):
docs: litmus-tests: Clarify about the RCU pre-initialization test
Documentation/litmus-tests/README | 24 +--
Documentation/litmus-tests/atomic/README | 16 -
tools/memory-model/Documentation/recipes.txt | 2 +-
.../MP+onceassign+derefonce.litmus| 0
tools/memory-model/litmus-tests/README| 3 +++
5 files changed, 26 insertions(+), 19 deletions(-)
delete mode 100644 Documentation/litmus-tests/atomic/README
rename {Documentation/litmus-tests/rcu =>
tools/memory-model/litmus-tests}/MP+onceassign+derefonce.litmus (100%)
--
2.17.1
[PATCH 4/3] docs: litmus-tests: Clarify about the RCU pre-initialization test
>From 7bb979aacd8788d174df8a56e9803ba9e5b7a381 Mon Sep 17 00:00:00 2001 From: Joel Fernandes (Google) Date: Mon, 11 May 2020 22:06:46 -0400 Subject: [PATCH 4/3] docs: litmus-tests: Clarify about the RCU pre-initialization test Since this test returned to tools/memory-model/, make sure that it is at least referenced from Documentation/litmus-tests/'s README. Co-developed-by: Joel Fernandes (Google) Co-developed-by: Akira Yokosawa [Alan: grammar nit] Suggested-by: Alan Stern Signed-off-by: Joel Fernandes (Google) Signed-off-by: Akira Yokosawa --- I said in the earlier message: > The explanation under tools/memory-model/litmus-tests/README also need the > same > rewording. , but obviously I was confused. It is good as is. This is on top of my earlier patch series. Joel, Alan, does this work with you? Thanks, Akira -- Documentation/litmus-tests/README | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index ac0b270b456c..b79e640214b9 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -24,6 +24,10 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus RCU (/rcu directory) +MP+onceassign+derefonce.litmus (under tools/memory-model/litmus-tests/) +Demonstrates the use of rcu_assign_pointer() and rcu_dereference() to +ensure that an RCU reader will not see pre-initialization garbage. + RCU+sync+read.litmus RCU+sync+free.litmus Both the above litmus tests demonstrate the RCU grace period guarantee -- 2.17.1
Re: [PATCH 0/3] tools/memory-model, Documentation/litmus-test: Sort out location of litmus test and README
On Tue, 12 May 2020 07:19:44 -0700, Paul E. McKenney wrote: > On Tue, May 12, 2020 at 08:19:36AM -0400, Joel Fernandes wrote: >> On Tue, May 12, 2020 at 08:50:45PM +0900, Akira Yokosawa wrote: >> [...] >>>> I think on top of this patch, I'd like to add a reference to the to the >>>> litmus test in tools/memory-model/ from Documentation/rcu/. >>> >>> Sounds reasonable to me. But for most people, it never changes its location. >>> Please find inline comments below. >>> >>>> >>>> Just to mention my rationale for Documentation/litmus-tests/rcu/, I was >>>> basically looking for a central place for RCU related litmus tests in the >>>> kernel sources and the idea of this new directory came up. >>>> >>>> For Akira's series, >>>> Acked-by: Joel Fernandes (Google) >>> >>> Thank you! >>> >>>> >>>> And could we add the following patch on top of Akira's series so we still >>>> maintain a reference to the moved RCU test?> >>>> ---8<--- >>>> >>>> From 52fdb57551cc769d8bd690f4f2b22de36ddece99 Mon Sep 17 00:00:00 2001 >>>> From: "Joel Fernandes (Google)" >>>> Date: Mon, 11 May 2020 22:06:46 -0400 >>>> Subject: [PATCH] docs: litmus-tests: Clarify about the RCU >>>> pre-initialization >>>> test >>>> >>>> Since this test was moved to tools/memory-model/, make sure that it is >>>> at least referenced from Documentation/litmus-tests/'s README. >>>> >>>> Signed-off-by: Joel Fernandes (Google) >>>> --- >>>> Documentation/litmus-tests/README | 6 -- >>>> 1 file changed, 4 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/Documentation/litmus-tests/README >>>> b/Documentation/litmus-tests/README >>>> index ac0b270b456c1..53f09e74734a4 100644 >>>> --- a/Documentation/litmus-tests/README >>>> +++ b/Documentation/litmus-tests/README >>>> @@ -11,7 +11,6 @@ tools/memory-model/README. >>>> >>>> atomic (/atomic derectory) >>>> -- >>>> - >>>> Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus >>>> Test that an atomic RMW followed by a smp_mb__after_atomic() is >>>> stronger than a normal acquire: both the read and write parts of >>>> @@ -23,8 +22,11 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus >>>> >>>> RCU (/rcu directory) >>>> >>>> - >>> >>> I loosely followed the convention of ReST documents in putting these empty >>> lines. But I don't mind if they are removed. >>> >>>> RCU+sync+read.litmus >>>> RCU+sync+free.litmus >>>> Both the above litmus tests demonstrate the RCU grace period guarantee >>>> that an RCU read-side critical section can never span a grace period. >>>> + >>>> +MP+onceassign+derefonce.litmus (moved to tools/memory-model/litmus-tests/) >>> >>> As I said above, for those who don't follow developments in the lkmm >>> branch, >>> MP+onceassign+derefonce.litmus stays in tools/memory-model/litmus-tests/. >>> So, >>> >>> +MP+onceassign+derefonce.litmus (under tools/memory-model/litmus-tests/) >>> >>> looks better to me. >> >> Yes it stays under tools/.. but is referenced here. Sounds like you agree and >> the only change from my follow-up patch that you want is to change "moved to" >> to "under". >> >> If so, Paul do you mind applying my patch and fixing this up? Or do you want >> to apply Akira's 3-patch series first and then have me send you another one >> on top? > > Let's get something that you, Akira, and Alan are good with, then I will > apply that, either on top of or in place of the current commits (just > tell me which). OK. I'm submitting a patch [4/3] with Alan's suggested-by and Joel's and my co-developed-by tags. The explanation under tools/memory-model/litmus-tests/README also need the same rewording. Thanks, Akira > > Thanx, Paul >
Re: [PATCH 0/3] tools/memory-model, Documentation/litmus-test: Sort out location of litmus test and README
On Mon, 11 May 2020 22:13:09 -0400, Joel Fernandes wrote: > On Mon, May 11, 2020 at 10:33:48AM -0700, Paul E. McKenney wrote: >> On Sun, May 10, 2020 at 04:21:02PM +0900, Akira Yokosawa wrote: >>> On Sat, 9 May 2020 12:43:30 +0900, Akira Yokosawa wrote: >>>> Hi Joel, >>>> >>>> Sorry for the late response but I've noticed some glitches. >>>> >>>> On Sun, 22 Mar 2020 21:57:32 -0400, Joel Fernandes (Google) wrote: >>>>> Move MP+onceassign+derefonce to the new Documentation/litmus-tests/rcu/ >>>>> directory. >>>> >>>> MP+onceassign+derefonce.litmus is called out in >>>> tools/memory-model/Documentation/recipes.txt as a representative example >>>> of RCU related litmus test. >>>> >>>> So I think it should be kept under tools/memory-model/litmus-tests. >>>> >>>> Further RCU-related litmus tests can be added under >>>> Documentation/litmus-tests/. >>>> >>>> IIUC, this change is not picked up by tip tree yet. So we have time to >>>> respin >>>> the series targeting v5.9. >>>> >>>>> >>>>> More RCU-related litmus tests would be added here. >>>>> >>>>> Signed-off-by: Joel Fernandes (Google) >>>>> >>>>> --- >>>>> Cc: vpil...@digitalocean.com >>>>> >>>>> Documentation/litmus-tests/README| 9 + >>>> >>>> Please note that later patches to add atomic litmus tests under >>>> Documentation/litmus-tests/ by Boqun put README as >>>> Documentation/litums-tests/atomic/README. >>>> >>>> This patch's location of RCU's README as Documentation/litmus-tests/README >>>> looks asymmetric to me. >>>> >>>> I'm OK with either merging atomic's README with the top-level one or >>>> moving RCU's README to under Documentation/litmus-tests/rcu. >>>> >>>> Joel, Boqum, can you sort out the location of README? >>> >>> So something like this? >>> >>> Patch 1/3 is an independent typo fix in recipes.txt. >>> Patch 2/3 reverts the MP+onceassign+derefonce relocation. >>> Patch 3/3 merges atomic's README into the top-level one. >>> >>> This is relative to -rcu's lkmm branch. >>> >>> Thoughts? >> >> Looks plausible to me, and thank you for reviewing this. >> >> Joel, thoughts? > > Sorry for the delays (OSPM conference in progress). I'm Ok with moving it > back to tools/memory-model/. > > I think on top of this patch, I'd like to add a reference to the to the > litmus test in tools/memory-model/ from Documentation/rcu/. Sounds reasonable to me. But for most people, it never changes its location. Please find inline comments below. > > Just to mention my rationale for Documentation/litmus-tests/rcu/, I was > basically looking for a central place for RCU related litmus tests in the > kernel sources and the idea of this new directory came up. > > For Akira's series, > Acked-by: Joel Fernandes (Google) Thank you! > > And could we add the following patch on top of Akira's series so we still > maintain a reference to the moved RCU test?> > ---8<--- > > From 52fdb57551cc769d8bd690f4f2b22de36ddece99 Mon Sep 17 00:00:00 2001 > From: "Joel Fernandes (Google)" > Date: Mon, 11 May 2020 22:06:46 -0400 > Subject: [PATCH] docs: litmus-tests: Clarify about the RCU pre-initialization > test > > Since this test was moved to tools/memory-model/, make sure that it is > at least referenced from Documentation/litmus-tests/'s README. > > Signed-off-by: Joel Fernandes (Google) > --- > Documentation/litmus-tests/README | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/litmus-tests/README > b/Documentation/litmus-tests/README > index ac0b270b456c1..53f09e74734a4 100644 > --- a/Documentation/litmus-tests/README > +++ b/Documentation/litmus-tests/README > @@ -11,7 +11,6 @@ tools/memory-model/README. > > atomic (/atomic derectory) > -- > - > Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus > Test that an atomic RMW followed by a smp_mb__after_atomic() is > stronger than a normal acquire: both the read and write parts of > @@ -23,8 +22,11 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus > > RCU (/rcu directory) > > - I loosely followed the convention of ReST documents in putting these empty lines. But I don't mind if they are removed. > RCU+sync+read.litmus > RCU+sync+free.litmus > Both the above litmus tests demonstrate the RCU grace period guarantee > that an RCU read-side critical section can never span a grace period. > + > +MP+onceassign+derefonce.litmus (moved to tools/memory-model/litmus-tests/) As I said above, for those who don't follow developments in the lkmm branch, MP+onceassign+derefonce.litmus stays in tools/memory-model/litmus-tests/. So, +MP+onceassign+derefonce.litmus (under tools/memory-model/litmus-tests/) looks better to me. Thanks, Akira > + Demonstrates that rcu_assign_pointer() and rcu_dereference() to > + ensure that an RCU reader will not see pre-initialization garbage. >
[PATCH 3/3] Documentation/litmus-tests: Merge atomic's README into top-level one
>From 1aa2c25f0ad16382a5bc597cdbdcc817645e01cd Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Sun, 10 May 2020 15:12:57 +0900 Subject: [PATCH 3/3] Documentation/litmus-tests: Merge atomic's README into top-level one Where Documentation/litmus-tests/README lists RCU litmus tests, Documentation/litmus-tests/atomic/README lists atomic litmus tests. For symmetry, merge the latter into former, with some context adjustment in the introduction. Signed-off-by: Akira Yokosawa --- Documentation/litmus-tests/README| 19 +++ Documentation/litmus-tests/atomic/README | 16 2 files changed, 19 insertions(+), 16 deletions(-) delete mode 100644 Documentation/litmus-tests/atomic/README diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index c4307ea9f996..ac0b270b456c 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -2,6 +2,25 @@ LITMUS TESTS +Each subdirectory contains litmus tests that are typical to describe the +semantics of respective kernel APIs. +For more information about how to "run" a litmus test or how to generate +a kernel test module based on a litmus test, please see +tools/memory-model/README. + + +atomic (/atomic derectory) +-- + +Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus +Test that an atomic RMW followed by a smp_mb__after_atomic() is +stronger than a normal acquire: both the read and write parts of +the RMW are ordered before the subsequential memory accesses. + +Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus +Test that atomic_set() cannot break the atomicity of atomic RMWs. + + RCU (/rcu directory) diff --git a/Documentation/litmus-tests/atomic/README b/Documentation/litmus-tests/atomic/README deleted file mode 100644 index 714cf93816ea.. --- a/Documentation/litmus-tests/atomic/README +++ /dev/null @@ -1,16 +0,0 @@ -This directory contains litmus tests that are typical to describe the semantics -of our atomic APIs. For more information about how to "run" a litmus test or -how to generate a kernel test module based on a litmus test, please see -tools/memory-model/README. - - -LITMUS TESTS - - -Atomic-RMW+mb__after_atomic-is-stronger-than-acquire - Test that an atomic RMW followed by a smp_mb__after_atomic() is - stronger than a normal acquire: both the read and write parts of - the RMW are ordered before the subsequential memory accesses. - -Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus - Test that atomic_set() cannot break the atomicity of atomic RMWs. -- 2.17.1
[PATCH 2/3] Revert "Documentation: LKMM: Move MP+onceassign+derefonce to new litmus-tests/rcu/"
>From 898051fee51913f5b9bd01cab98beb8944ec50b2 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sun, 10 May 2020 13:43:34 +0900
Subject: [PATCH 2/3] Revert "Documentation: LKMM: Move MP+onceassign+derefonce
to new litmus-tests/rcu/"
This reverts commit a5cca3485d9206a9dbbc6f47d2a537e69b53cd82.
MP+onceassign+derefonce.litmus is called out from
tools/memory-model/Documentation/recipes.txt.
It should be in the same directory as the other representative tests
to help readers inspect it.
Signed-off-by: Akira Yokosawa
---
Documentation/litmus-tests/README | 3 ---
.../memory-model/litmus-tests}/MP+onceassign+derefonce.litmus | 0
tools/memory-model/litmus-tests/README | 3 +++
3 files changed, 3 insertions(+), 3 deletions(-)
rename {Documentation/litmus-tests/rcu =>
tools/memory-model/litmus-tests}/MP+onceassign+derefonce.litmus (100%)
diff --git a/Documentation/litmus-tests/README
b/Documentation/litmus-tests/README
index 79d187f75679..c4307ea9f996 100644
--- a/Documentation/litmus-tests/README
+++ b/Documentation/litmus-tests/README
@@ -4,9 +4,6 @@ LITMUS TESTS
RCU (/rcu directory)
-MP+onceassign+derefonce.litmus
-Demonstrates that rcu_assign_pointer() and rcu_dereference() to
-ensure that an RCU reader will not see pre-initialization garbage.
RCU+sync+read.litmus
RCU+sync+free.litmus
diff --git a/Documentation/litmus-tests/rcu/MP+onceassign+derefonce.litmus
b/tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus
similarity index 100%
rename from Documentation/litmus-tests/rcu/MP+onceassign+derefonce.litmus
rename to tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus
diff --git a/tools/memory-model/litmus-tests/README
b/tools/memory-model/litmus-tests/README
index 79e1b1ed4929..681f9067fa9e 100644
--- a/tools/memory-model/litmus-tests/README
+++ b/tools/memory-model/litmus-tests/README
@@ -63,6 +63,9 @@ LB+poonceonces.litmus
As above, but with store-release replaced with WRITE_ONCE()
and load-acquire replaced with READ_ONCE().
+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
--
2.17.1
[PATCH 1/3] tools/memory-model: Fix reference to litmus test in recipes.txt
>From c171026a697d401ea5d2ad6656d0481944604b14 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sun, 10 May 2020 13:37:14 +0900
Subject: [PATCH 1/3] tools/memory-model: Fix reference to litmus test in
recipes.txt
The name of litmus test doesn't match the one described below.
Fix the name of litmus test.
Signed-off-by: Akira Yokosawa
---
tools/memory-model/Documentation/recipes.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/memory-model/Documentation/recipes.txt
b/tools/memory-model/Documentation/recipes.txt
index 7fe8d7aa3029..63c4adfed884 100644
--- a/tools/memory-model/Documentation/recipes.txt
+++ b/tools/memory-model/Documentation/recipes.txt
@@ -126,7 +126,7 @@ However, it is not necessarily the case that accesses
ordered by
locking will be seen as ordered by CPUs not holding that lock.
Consider this example:
- /* See Z6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus. */
+ /* See Z6.0+pooncelock+pooncelock+pombonce.litmus. */
void CPU0(void)
{
spin_lock();
--
2.17.1
[PATCH 0/3] tools/memory-model, Documentation/litmus-test: Sort out location of litmus test and README
On Sat, 9 May 2020 12:43:30 +0900, Akira Yokosawa wrote:
> Hi Joel,
>
> Sorry for the late response but I've noticed some glitches.
>
> On Sun, 22 Mar 2020 21:57:32 -0400, Joel Fernandes (Google) wrote:
>> Move MP+onceassign+derefonce to the new Documentation/litmus-tests/rcu/
>> directory.
>
> MP+onceassign+derefonce.litmus is called out in
> tools/memory-model/Documentation/recipes.txt as a representative example
> of RCU related litmus test.
>
> So I think it should be kept under tools/memory-model/litmus-tests.
>
> Further RCU-related litmus tests can be added under
> Documentation/litmus-tests/.
>
> IIUC, this change is not picked up by tip tree yet. So we have time to respin
> the series targeting v5.9.
>
>>
>> More RCU-related litmus tests would be added here.
>>
>> Signed-off-by: Joel Fernandes (Google)
>>
>> ---
>> Cc: vpil...@digitalocean.com
>>
>> Documentation/litmus-tests/README| 9 +
>
> Please note that later patches to add atomic litmus tests under
> Documentation/litmus-tests/ by Boqun put README as
> Documentation/litums-tests/atomic/README.
>
> This patch's location of RCU's README as Documentation/litmus-tests/README
> looks asymmetric to me.
>
> I'm OK with either merging atomic's README with the top-level one or
> moving RCU's README to under Documentation/litmus-tests/rcu.
>
> Joel, Boqum, can you sort out the location of README?
So something like this?
Patch 1/3 is an independent typo fix in recipes.txt.
Patch 2/3 reverts the MP+onceassign+derefonce relocation.
Patch 3/3 merges atomic's README into the top-level one.
This is relative to -rcu's lkmm branch.
Thoughts?
Thanks, Akira
--
Akira Yokosawa (3):
tools/memory-model: Fix reference to litmus test in recipes.txt
Revert "Documentation: LKMM: Move MP+onceassign+derefonce to new
litmus-tests/rcu/"
Documentation/litmus-tests: Merge atomic's README into top-level one
Documentation/litmus-tests/README | 22 ---
Documentation/litmus-tests/atomic/README | 16 --
tools/memory-model/Documentation/recipes.txt | 2 +-
.../MP+onceassign+derefonce.litmus| 0
tools/memory-model/litmus-tests/README| 3 +++
5 files changed, 23 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/litmus-tests/atomic/README
rename {Documentation/litmus-tests/rcu =>
tools/memory-model/litmus-tests}/MP+onceassign+derefonce.litmus (100%)
--
2.17.1
Re: [PATCH v2 1/4] Documentation: LKMM: Move MP+onceassign+derefonce to new litmus-tests/rcu/
Hi Joel,
Sorry for the late response but I've noticed some glitches.
On Sun, 22 Mar 2020 21:57:32 -0400, Joel Fernandes (Google) wrote:
> Move MP+onceassign+derefonce to the new Documentation/litmus-tests/rcu/
> directory.
MP+onceassign+derefonce.litmus is called out in
tools/memory-model/Documentation/recipes.txt as a representative example
of RCU related litmus test.
So I think it should be kept under tools/memory-model/litmus-tests.
Further RCU-related litmus tests can be added under Documentation/litmus-tests/.
IIUC, this change is not picked up by tip tree yet. So we have time to respin
the series targeting v5.9.
>
> More RCU-related litmus tests would be added here.
>
> Signed-off-by: Joel Fernandes (Google)
>
> ---
> Cc: vpil...@digitalocean.com
>
> Documentation/litmus-tests/README| 9 +
Please note that later patches to add atomic litmus tests under
Documentation/litmus-tests/ by Boqun put README as
Documentation/litums-tests/atomic/README.
This patch's location of RCU's README as Documentation/litmus-tests/README
looks asymmetric to me.
I'm OK with either merging atomic's README with the top-level one or
moving RCU's README to under Documentation/litmus-tests/rcu.
Joel, Boqum, can you sort out the location of README?
Thanks, Akira
> .../litmus-tests/rcu}/MP+onceassign+derefonce.litmus | 0
> tools/memory-model/litmus-tests/README | 3 ---
> 3 files changed, 9 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/litmus-tests/README
> rename {tools/memory-model/litmus-tests =>
> Documentation/litmus-tests/rcu}/MP+onceassign+derefonce.litmus (100%)
>
> diff --git a/Documentation/litmus-tests/README
> b/Documentation/litmus-tests/README
> new file mode 100644
> index 0..84208bc197f2e
> --- /dev/null
> +++ b/Documentation/litmus-tests/README
> @@ -0,0 +1,9 @@
> +
> +LITMUS TESTS
> +
> +
> +RCU (/rcu directory)
> +
> +MP+onceassign+derefonce.litmus
> +Demonstrates that rcu_assign_pointer() and rcu_dereference() to
> +ensure that an RCU reader will not see pre-initialization garbage.
> diff --git a/tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus
> b/Documentation/litmus-tests/rcu/MP+onceassign+derefonce.litmus
> similarity index 100%
> rename from tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus
> rename to Documentation/litmus-tests/rcu/MP+onceassign+derefonce.litmus
> diff --git a/tools/memory-model/litmus-tests/README
> b/tools/memory-model/litmus-tests/README
> index 681f9067fa9ed..79e1b1ed4929a 100644
> --- a/tools/memory-model/litmus-tests/README
> +++ b/tools/memory-model/litmus-tests/README
> @@ -63,9 +63,6 @@ LB+poonceonces.litmus
> As above, but with store-release replaced with WRITE_ONCE()
> and load-acquire replaced with READ_ONCE().
>
> -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
>
Re: [PATCH 00/14] Move the ReST files from Documentation/*.txt
(CC to documentation, get_maintainer, and LKMM maintainers)
Hi Mauro,
As I didn't receive "[PATCH 12/14] docs: move remaining stuff under
Documentation/*.txt to Documentation/staging", I'm replying to
[PATCH 00/14].
On Fri, 1 May 2020 17:37:44 +0200, Mauro Carvalho Chehab wrote:
> The main goal of this series is to cleanup the Documentation/
> directory.
>
> Most of the files under Documentation/*.txt are already in ReST format.
> They just need to be moved to some place. So, most of the work here is
> to just move files for them to generate an output using the docs building
> system.
>
> After this change, the Documentation/ dir will contain:
>
> - the main ReST file:
> - index.rst
>
> - TUX and its copyright:
> - logo.gif and COPYING-logo
>
> - Files required to do ReST builds:
> - .gitignore, Makefile, conf.py, docutils.conf, Kconfig
>
> - A pre-git file used to generate patches:
> - dontdiff
> (I guess we should get rid of it, as I doubt this is useful those days).
>
> -
>
> Besides the above rightful files, the Documentation/ dir will also
> contain some left-overs:
>
> - two somewhat new ReST files that should be moved to somewhere:
> - asm-annotations.rst and watch_queue.rst
>
> - Two files that helps people looking for some well known documents
> that are referenced at the web, pointing to their new location inside
> the process/ dir:
> - SubmittingPatches and CodingStyle
>
> - Three .txt files that weren't converted to ReST:
> - atomic_bitops.txt, memory-barriers.txt, atomic_t.txt
>
> It should be noticed that I'm in doubt about the location of some files,
> and some stuff may well belong to a trash can. So, this series create
> a temporary place for orphaned documents in the form of a
> Documentation/staging directory.
>
> This series is also on my development git tree, at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=rename-main-docs
>
> The built output documentation on html format is at:
>
> https://www.infradead.org/~mchehab/kernel_docs/
>
> (it contains also other documents I converted to ReST)
>
>
> Mauro Carvalho Chehab (14):
> docs: move DMA kAPI to Documentation/core-api
> docs: add bus-virt-phys-mapping.txt to core-api
> docs: fix references for DMA*.txt files
> docs: move IPMI.txt to the driver API book
> docs: fix references for ipmi.rst file
> docs: debugging-via-ohci1394.txt: add it to the core-api book
> docs: add IRQ documentation at the core-api book
> docs: move kobject and kref docs into the core-api book
> docs: move digsig docs to the security book
> docs: move locking-specific documenta to locking/ directory
> docs: move other kAPI documents to core-api
> docs: move remaining stuff under Documentation/*.txt to
> Documentation/staging
> docs: staging: don't use literalinclude
> docs: staging: use small font for literal includes
>
> Documentation/PCI/pci.rst | 6 +-
> Documentation/admin-guide/hw-vuln/l1tf.rst| 2 +-
> .../admin-guide/kernel-parameters.txt | 2 +-
> .../admin-guide/kernel-per-CPU-kthreads.rst | 2 +-
> Documentation/admin-guide/sysctl/vm.rst | 2 +-
> Documentation/block/biodoc.rst| 2 +-
> .../bus-virt-phys-mapping.rst}| 2 +-
> .../debugging-via-ohci1394.rst} | 0
> .../dma-api-howto.rst}| 0
> .../{DMA-API.txt => core-api/dma-api.rst} | 6 +-
> .../dma-attributes.rst} | 0
> .../dma-isa-lpc.rst} | 2 +-
> Documentation/core-api/index.rst | 14 +
> .../{IRQ.txt => core-api/irq/concepts.rst}| 0
> Documentation/core-api/irq/index.rst | 11
> .../irq/irq-affinity.rst} | 0
> .../irq/irq-domain.rst} | 3 +-
> .../irq/irqflags-tracing.rst} | 0
> Documentation/core-api/kobject.rst| 2 +-
> Documentation/{kref.txt => core-api/kref.rst} | 0
> .../{mailbox.txt => core-api/mailbox.rst} | 0
> .../nommu-mmap.rst} | 0
> .../this_cpu_ops.rst} | 0
> .../unaligned-memory-access.rst} | 0
> Documentation/driver-api/index.rst| 1 +
> .../{IPMI.txt => driver-api/ipmi.rst} | 0
> Documentation/driver-api/usb/dma.rst | 6 +-
> Documentation/gpu/drm-mm.rst | 2 +-
> Documentation/ia64/irq-redir.rst | 2 +-
> Documentation/index.rst | 13
> .../futex-requeue-pi.rst} | 0
> .../hwspinlock.rst} | 0
> Documentation/locking/index.rst | 7 +++
> .../percpu-rw-semaphore.rst} | 0
> .../{pi-futex.txt => locking/pi-futex.rst}| 0
> .../preempt-locking.rst} | 0
> .../robust-futex-ABI.rst}
[PATCH 2/2] tools/memory-model: Mention data-race capability in jugdelitmus.sh's header
>From 67092cb93f7a0fd3c4f9a300637e4f5c61fc944a Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Wed, 14 Aug 2019 17:48:25 +0900
Subject: [PATCH 2/2] tools/memory-model: Mention data-race capability in
jugdelitmus.sh's header
Replicate description of data-race capability from the change log of
commit ("tools/memory-model: Add data-race capabilities to
judgelitmus.sh") in the header comment.
Signed-off-by: Akira Yokosawa
---
tools/memory-model/scripts/judgelitmus.sh | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/tools/memory-model/scripts/judgelitmus.sh
b/tools/memory-model/scripts/judgelitmus.sh
index c91130814593..1ec5d89fcfbb 100755
--- a/tools/memory-model/scripts/judgelitmus.sh
+++ b/tools/memory-model/scripts/judgelitmus.sh
@@ -4,13 +4,19 @@
# Given a .litmus test and the corresponding litmus output file, check
# the .litmus.out file against the "Result:" comment to judge whether the
# test ran correctly. If the --hw argument is omitted, check against the
-# LKMM output, which is assumed to be in file.litmus.out. If this argument
-# is provided, this is assumed to be a hardware test, and the output is
-# assumed to be in file.litmus.HW.out, where "HW" is the --hw argument.
-# In addition, non-Sometimes verification results will be noted, but
-# forgiven. Furthermore, if there is no "Result:" comment but there is
-# an LKMM .litmus.out file, the observation in that file will be used
-# to judge the assembly-language verification.
+# LKMM output, which is assumed to be in file.litmus.out. If either a
+# "DATARACE" marker in the "Result:" comment or a "Flag data-race" marker
+# in the LKMM output is present, the other must also be as well, at least
+# for litmus tests having a "Result:" comment. In this case, a failure of
+# the Always/Sometimes/Never portion of the "Result:" prediction will be
+# noted, but forgiven.
+#
+# If the --hw argument is provided, this is assumed to be a hardware
+# test, and the output is assumed to be in file.litmus.HW.out, where
+# "HW" is the --hw argument. In addition, non-Sometimes verification
+# results will be noted, but forgiven. Furthermore, if there is no
+# "Result:" comment but there is an LKMM .litmus.out file, the observation
+# in that file will be used to judge the assembly-language verification.
#
# Usage:
# judgelitmus.sh file.litmus
--
2.17.1
Subject: [PATCH 1/2] tools/memory-model: Reflect updated file name convention in judgelitmus.sh
>From 6251ebb775a81f1ac158f197ad8110b8f98c4248 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Wed, 14 Aug 2019 17:20:54 +0900
Subject: [PATCH 1/2] tools/memory-model: Reflect updated file name convention
in judgelitmus.sh
Commit ("tools/memory-model: Move from .AArch64.litmus.out to
.litmus.AArch.out") swapped "HW" and "litmus" part in .out file name.
Reflect the change in header comment in judgelitmus.sh
Signed-off-by: Akira Yokosawa
---
tools/memory-model/scripts/judgelitmus.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/memory-model/scripts/judgelitmus.sh
b/tools/memory-model/scripts/judgelitmus.sh
index 6408c012bdf5..c91130814593 100755
--- a/tools/memory-model/scripts/judgelitmus.sh
+++ b/tools/memory-model/scripts/judgelitmus.sh
@@ -6,7 +6,7 @@
# test ran correctly. If the --hw argument is omitted, check against the
# LKMM output, which is assumed to be in file.litmus.out. If this argument
# is provided, this is assumed to be a hardware test, and the output is
-# assumed to be in file.HW.litmus.out, where "HW" is the --hw argument.
+# assumed to be in file.litmus.HW.out, where "HW" is the --hw argument.
# In addition, non-Sometimes verification results will be noted, but
# forgiven. Furthermore, if there is no "Result:" comment but there is
# an LKMM .litmus.out file, the observation in that file will be used
--
2.17.1
[PATCH 0/2] tools/memory-model: Update comment of jugdelitmus.sh
Hi Paul,
I see some inconsistency between the header comment of judgelitmus.sh
and the updated script.
This patch set updates the header. It is relative to current lkmm-dev
of -rcu.
Patch 1/2 corresponds to ("tools/memory-model: Move from
.AArch64.litmus.out to .litmus.AArch.out").
Patch 2/2 corresponds to ("tools/memory-model: Add data-race
capabilities to judgelitmus.sh").
You should be able to use each patch as a fix-up commit respectively.
I'm OK either with them applied at the head of the branch or
with them merged into your commits.
Thanks, Akira
--
Akira Yokosawa (2):
tools/memory-model: Reflect updated file name convention in
judgelitmus.sh
tools/memory-model: Mention data-race capability in jugdelitmus.sh's
header
tools/memory-model/scripts/judgelitmus.sh | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
--
2.17.1
Re: [PATCH RFC memory-model 27/31] tools/memory-model: Add data-race capabilities to judgelitmus.sh
Hi Paul,
(CC: using Andrea's gmail address, adding Daniel)
Sorry for slow response, but please find inline comments below.
On Thu, 1 Aug 2019 15:20:52 -0700, Paul E. McKenney wrote:
> This commit adds functionality to judgelitmus.sh to allow it to handle
> both the "DATARACE" markers in the "Result:" comments in litmus tests
> and the "Flag data-race" markers in LKMM output. For C-language tests,
> if either marker is present, the other must also be as well, at least for
> litmus tests having a "Result:" comment. If the LKMM output indicates
> a data race, then failures of the Always/Sometimes/Never portion of the
> "Result:" prediction are forgiven.
I'd like to see the reason _why_ they can be forgiven. Also, updating
the header comment of judgelitimus.sh to mention these expansions would
be of much help.
My guess is any data-race would moot the Always/Sometimes/Never
prediction.
This reminds me that update of LKMM documentation regarding plain
accesses (data races) is yet to come.
Thanks, Akira
>
> Signed-off-by: Paul E. McKenney
> ---
> tools/memory-model/scripts/judgelitmus.sh | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/tools/memory-model/scripts/judgelitmus.sh
> b/tools/memory-model/scripts/judgelitmus.sh
> index ca9a19829d79..eaa2cc7d3b36 100755
> --- a/tools/memory-model/scripts/judgelitmus.sh
> +++ b/tools/memory-model/scripts/judgelitmus.sh
> @@ -47,9 +47,27 @@ else
> echo ' --- ' error: \"$LKMM_DESTDIR/$litmusout is not a readable file
> exit 255
> fi
> +if grep -q '^Flag data-race$' "$LKMM_DESTDIR/$litmusout"
> +then
> + datarace_modeled=1
> +fi
> if grep -q '^ \* Result: ' $litmus
> then
> outcome=`grep -m 1 '^ \* Result: ' $litmus | awk '{ print $3 }'`
> + if grep -m1 '^ \* Result: .* DATARACE' $litmus
> + then
> + datarace_predicted=1
> + fi
> + if test -n "$datarace_predicted" -a -z "$datarace_modeled" -a -z
> "$LKMM_HW_MAP_FILE"
> + then
> + echo '!!! Predicted data race not modeled' $litmus
> + exit 252
> + elif test -z "$datarace_predicted" -a -n "$datarace_modeled"
> + then
> + # Note that hardware models currently don't model data races
> + echo '!!! Unexpected data race modeled' $litmus
> + exit 253
> + fi
> elif test -n "$LKMM_HW_MAP_FILE" && grep -q '^Observation'
> $LKMM_DESTDIR/$lkmmout > /dev/null 2>&1
> then
> outcome=`grep -m 1 '^Observation ' $LKMM_DESTDIR/$lkmmout | awk '{
> print $3 }'`
> @@ -114,7 +132,7 @@ elif grep '^Observation' $LKMM_DESTDIR/$litmusout | grep
> -q $outcome || test "$o
> then
> ret=0
> else
> - if test -n "$LKMM_HW_MAP_FILE" -a "$outcome" = Sometimes
> + if test \( -n "$LKMM_HW_MAP_FILE" -a "$outcome" = Sometimes \) -o -n
> "$datarace_modeled"
> then
> flag="--- Forgiven"
> ret=0
>
Re: [PATCH] MAINTAINERS: Update e-mail address for Andrea Parri
On Mon, 5 Aug 2019 14:15:17 +0200, Andrea Parri wrote:
> My @amarulasolutions.com address stopped working this July, so update
> to my @gmail.com address where you'll still be able to reach me.
>
> Signed-off-by: Andrea Parri
> 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: Daniel Lustig
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Andrea,
Why don't you also add an entry in .mailmap as Will did in commit
c584b1202f2d ("MAINTAINERS: Update my email address to use @kernel.org")?
Thanks, Akira
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6426db5198f05..527317026492f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9326,7 +9326,7 @@ F: drivers/misc/lkdtm/*
>
> LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)
> M: Alan Stern
> -M: Andrea Parri
> +M: Andrea Parri
> M: Will Deacon
> M: Peter Zijlstra
> M: Boqun Feng
>
Re: [PATCH 3/3] tools: memory-model: Improve data-race detection
Hi Paul and Alan, On 2019/06/22 8:54, Paul E. McKenney wrote: > On Fri, Jun 21, 2019 at 10:25:23AM -0400, Alan Stern wrote: >> On Fri, 21 Jun 2019, Andrea Parri wrote: >> >>> On Thu, Jun 20, 2019 at 11:55:58AM -0400, Alan Stern wrote: >>>> Herbert Xu recently reported a problem concerning RCU and compiler >>>> barriers. In the course of discussing the problem, he put forth a >>>> litmus test which illustrated a serious defect in the Linux Kernel >>>> Memory Model's data-race-detection code. I was not involved in the mail thread and wondering what the litmus test looked like. Some searching of the archive has suggested that Alan presented a properly formatted test based on Herbert's idea in [1]. [1]: https://lore.kernel.org/lkml/pine.lnx.4.44l0.1906041026570.1731-100...@iolanthe.rowland.org/ If this is the case, adding the link (or message id) in the change log would help people see the circumstances, I suppose. Paul, can you amend the change log? I ran herd7 on said litmus test at both "lkmm" and "dev" of -rcu and confirmed that this patch fixes the result. So, Tested-by: Akira Yokosawa Thanks, Akira >>>> >>>> The defect was that the LKMM assumed visibility and executes-before >>>> ordering of plain accesses had to be mediated by marked accesses. In >>>> Herbert's litmus test this wasn't so, and the LKMM claimed the litmus >>>> test was allowed and contained a data race although neither is true. >>>> >>>> In fact, plain accesses can be ordered by fences even in the absence >>>> of marked accesses. In most cases this doesn't matter, because most >>>> fences only order accesses within a single thread. But the rcu-fence >>>> relation is different; it can order (and induce visibility between) >>>> accesses in different threads -- events which otherwise might be >>>> concurrent. This makes it relevant to data-race detection. >>>> >>>> This patch makes two changes to the memory model to incorporate the >>>> new insight: >>>> >>>>If a store is separated by a fence from another access, >>>>the store is necessarily visible to the other access (as >>>>reflected in the ww-vis and wr-vis relations). Similarly, >>>>if a load is separated by a fence from another access then >>>>the load necessarily executes before the other access (as >>>>reflected in the rw-xbstar relation). >>>> >>>>If a store is separated by a strong fence from a marked access >>>>then it is necessarily visible to any access that executes >>>>after the marked access (as reflected in the ww-vis and wr-vis >>>>relations). >>>> >>>> With these changes, the LKMM gives the desired result for Herbert's >>>> litmus test and other related ones. >>>> >>>> Signed-off-by: Alan Stern >>>> Reported-by: Herbert Xu >>> >>> For the entire series: >>> >>> Acked-by: Andrea Parri >>> >>> Two nits, but up to Paul AFAIAC: >>> >>> - This is a first time for "tools: memory-model:" in Subject; we were >>>kind of converging to "tools/memory-model:"... >> >> Yeah, sure. That's the sort of detail I have a hard time remembering. >> >>> - The report preceded the patch; we might as well reflect this in the >>>order of the tags. >> >> Either way is okay with me. > > I applied Andrea's acks and edited as called out above, thank you both! > > Thanx, Paul >
Re: Adding plain accesses and detecting data races in the LKMM
On Fri, 19 Apr 2019 11:06:41 -0700, Paul E. McKenney wrote:
> On Sat, Apr 20, 2019 at 12:06:58AM +0900, Akira Yokosawa wrote:
>> Hi Paul,
>>
[...]
>
>>> + (1) The compiler can reorder the load from a to precede the
>>> + atomic_dec(), (2) Because x86 smp_mb__before_atomic() is only a
>>> + compiler barrier, the CPU can reorder the preceding store to
>>> + obj->dead with the later load from a.
>>> +
>>> + This could be avoided by using READ_ONCE(), which would prevent the
>>> + compiler from reordering due to both atomic_dec() and READ_ONCE()
>>> + being volatile accesses, and is usually preferable for loads from
>>> + shared variables. However, weakly ordered CPUs would still be
>>> + free to reorder the atomic_dec() with the load from a, so a more
>>> + readable option is to also use smp_mb__after_atomic() as follows:
>>
>> The point here is not just "readability", but also the portability of the
>> code, isn't it?
>
> As Andrea noted, in this particular case, the guarantee that the
> store to obj->dead precedes the load from x is portable. Either the
> smp_mb__before_atomic() or the atomic_dec() must provide the ordering.
I think I understood this. What I wanted to say was the code for x86 implied
in the subjunctive sentence:
obj->dead = 1;
smp_mb__before_atomic();
atomic_dec(>ref_count);
r1 = READ_ONCE(x);
, which was not spelled out, is not portable if we expect the ordering of
atomic_dec() with READ_ONCE().
> However, you are right that there is some non-portability. But this
> non-portability involves the order of the atomic_dec() and the store to x.
Yes, you've guessed it right.
>
> So what I did was ...
>
>> Thanks, Akira
>>
>>> +
>>> + WRITE_ONCE(obj->dead, 1);
>>> + smp_mb__before_atomic();
>>> + atomic_dec(>ref_count);
>>> + smp_mb__after_atomic();
>>> + r1 = READ_ONCE(a);
>>> +
>>> + This orders all three accesses against each other, and also makes
>>> + the intent quite clear.
>
> ... change the above paragraph to read as follows:
>
> In addition, the example without the smp_mb__after_atomic() does
> not necessarily order the atomic_dec() with the load from x.
> In contrast, the example with both smp_mb__before_atomic() and
> smp_mb__after_atomic() orders all three accesses against each other,
> and also makes the intent quite clear.
>
> Does that help?
This looks a little bit redundant to me. The original one is clear
enough.
How about editing the leading sentence above:
>>> + shared variables. However, weakly ordered CPUs would still be
>>> + free to reorder the atomic_dec() with the load from a, so a more
>>> + readable option is to also use smp_mb__after_atomic() as follows:
to read as follows?
shared variables. However, weakly ordered CPUs would still be
free to reorder the atomic_dec() with the load from x, so a
portable and more readable option is to also use
smp_mb__after_atomic() as follows:
Obviously, the interesting discussion going on in another thread will
surely affect this patch.
Thanks, Akira
>
> Thanx, Paul
>
>>> See Documentation/atomic_{t,bitops}.txt for more information.
>>>
>>> diff --git a/tools/memory-model/linux-kernel.cat
>>> b/tools/memory-model/linux-kernel.cat
>>> index 8dcb37835b61..b6866f93abb8 100644
>>> --- a/tools/memory-model/linux-kernel.cat
>>> +++ b/tools/memory-model/linux-kernel.cat
>>> @@ -28,8 +28,8 @@ include "lock.cat"
>>> let rmb = [R \ Noreturn] ; fencerel(Rmb) ; [R \ Noreturn]
>>> let wmb = [W] ; fencerel(Wmb) ; [W]
>>> let mb = ([M] ; fencerel(Mb) ; [M]) |
>>> - ([M] ; fencerel(Before-atomic) ; [RMW] ; po? ; [M]) |
>>> - ([M] ; po? ; [RMW] ; fencerel(After-atomic) ; [M]) |
>>> + ([M] ; fencerel(Before-atomic) ; [RMW]) |
>>> + ([RMW] ; fencerel(After-atomic) ; [M]) |
>>> ([M] ; po? ; [LKW] ; fencerel(After-spinlock) ; [M]) |
>>> ([M] ; po ; [UL] ; (co | po) ; [LKW] ;
>>> fencerel(After-unlock-lock) ; [M])
>>>
>>
>
Re: Adding plain accesses and detecting data races in the LKMM
Hi Paul,
Please find inline comments below.
On Fri, 19 Apr 2019 05:47:20 -0700, Paul E. McKenney wrote:
> On Fri, Apr 19, 2019 at 02:53:02AM +0200, Andrea Parri wrote:
>>> Are you saying that on x86, atomic_inc() acts as a full memory barrier
>>> but not as a compiler barrier, and vice versa for
>>> smp_mb__after_atomic()? Or that neither atomic_inc() nor
>>> smp_mb__after_atomic() implements a full memory barrier?
>>
>> I'd say the former; AFAICT, these boil down to:
>>
>>
>> https://elixir.bootlin.com/linux/v5.1-rc5/source/arch/x86/include/asm/atomic.h#L95
>>
>> https://elixir.bootlin.com/linux/v5.1-rc5/source/arch/x86/include/asm/barrier.h#L84
>
> OK, how about the following?
>
> Thanx, Paul
>
>
>
> commit 19d166dadc4e1bba4b248fb46d32ca4f2d10896b
> Author: Paul E. McKenney
> Date: Fri Apr 19 05:20:30 2019 -0700
>
> tools/memory-model: Make smp_mb__{before,after}_atomic() match x86
>
> Read-modify-write atomic operations that do not return values need not
> provide any ordering guarantees, and this means that both the compiler
> and the CPU are free to reorder accesses across things like atomic_inc()
> and atomic_dec(). The stronger systems such as x86 allow the compiler
> to do the reordering, but prevent the CPU from so doing, and these
> systems implement smp_mb__{before,after}_atomic() as compiler barriers.
> The weaker systems such as Power allow both the compiler and the CPU
> to reorder accesses across things like atomic_inc() and atomic_dec(),
> and implement smp_mb__{before,after}_atomic() as full memory barriers.
>
> This means that smp_mb__before_atomic() only orders the atomic operation
> itself with accesses preceding the smp_mb__before_atomic(), and does
> not necessarily provide any ordering whatsoever against accesses
> folowing the atomic operation. Similarly, smp_mb__after_atomic()
s/folowing/following/
> only orders the atomic operation itself with accesses following the
> smp_mb__after_atomic(), and does not necessarily provide any ordering
> whatsoever against accesses preceding the atomic operation. Full ordering
> therefore requires both an smp_mb__before_atomic() before the atomic
> operation and an smp_mb__after_atomic() after the atomic operation.
>
> Therefore, linux-kernel.cat's current model of Before-atomic
> and After-atomic is too strong, as it guarantees ordering of
> accesses on the other side of the atomic operation from the
> smp_mb__{before,after}_atomic(). This commit therefore weakens
> the guarantee to match the semantics called out above.
>
> Reported-by: Andrea Parri
> Suggested-by: Alan Stern
> Signed-off-by: Paul E. McKenney
>
> diff --git a/Documentation/memory-barriers.txt
> b/Documentation/memory-barriers.txt
> index 169d938c0b53..e5b97c3e8e39 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -1888,7 +1888,37 @@ There are some more advanced barrier functions:
> atomic_dec(>ref_count);
>
> This makes sure that the death mark on the object is perceived to be set
> - *before* the reference counter is decremented.
> + *before* the reference counter is decremented. However, please note
> + that smp_mb__before_atomic()'s ordering guarantee does not necessarily
> + extend beyond the atomic operation. For example:
> +
> + obj->dead = 1;
> + smp_mb__before_atomic();
> + atomic_dec(>ref_count);
> + r1 = a;
> +
> + Here the store to obj->dead is not guaranteed to be ordered with
> + with the load from a. This reordering can happen on x86 as follows:
s/with//
And I beg you to avoid using the single letter variable "a".
It's confusing.
> + (1) The compiler can reorder the load from a to precede the
> + atomic_dec(), (2) Because x86 smp_mb__before_atomic() is only a
> + compiler barrier, the CPU can reorder the preceding store to
> + obj->dead with the later load from a.
> +
> + This could be avoided by using READ_ONCE(), which would prevent the
> + compiler from reordering due to both atomic_dec() and READ_ONCE()
> + being volatile accesses, and is usually preferable for loads from
> + shared variables. However, weakly ordered CPUs would still be
> + free to reorder the atomic_dec() with the load from a, so a more
> + readable option is to also use smp_mb__after_atomic() as follows:
The point here is not just "readability", but also the portability of the
code, isn't it?
Thanks, Akira
> +
> + WRITE_ONCE(obj->dead, 1);
> + smp_mb__before_atomic();
> + atomic_dec(>ref_count);
> + smp_mb__after_atomic();
> + r1 = READ_ONCE(a);
> +
> + This orders all three accesses against each other, and also makes
> + the
Re: [PATCH tip/core/rcu 04/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
On Thu, 4 Apr 2019 17:40:22 +0100, Will Deacon wrote:
> Hi Akira,
>
> On Fri, Apr 05, 2019 at 12:58:36AM +0900, Akira Yokosawa wrote:
>> On Tue, 2 Apr 2019 14:03:46 +0100, Will Deacon wrote:
>>> On Tue, Mar 26, 2019 at 04:41:16PM -0700, Paul E. McKenney wrote:
>>>> From: Will Deacon
>>>>
>>>> The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt is vague,
>>>> x86-centric, out-of-date, incomplete and demonstrably incorrect in places.
>>>> This is largely because I/O ordering is a horrible can of worms, but also
>>>> because the document has stagnated as our understanding has evolved.
>>>>
>>>> Attempt to address some of that, by rewriting the section based on
>>>> recent(-ish) discussions with Arnd, BenH and others. Maybe one day we'll
>>>> find a way to formalise this stuff, but for now let's at least try to
>>>> make the English easier to understand.
>>>>
>>>> Cc: "Paul E. McKenney"
>>>> Cc: Benjamin Herrenschmidt
>>>> Cc: Michael Ellerman
>>>> Cc: Arnd Bergmann
>>>> Cc: Peter Zijlstra
>>>> Cc: Andrea Parri
>>>> Cc: Palmer Dabbelt
>>>> Cc: Daniel Lustig
>>>> Cc: David Howells
>>>> Cc: Alan Stern
>>>> Cc: Linus Torvalds
>>>> Cc: "Maciej W. Rozycki"
>>>> Cc: Mikulas Patocka
>>>> Signed-off-by: Will Deacon
>>>> Signed-off-by: Paul E. McKenney
>>>> ---
>>>> Documentation/memory-barriers.txt | 115 ++
>>>> 1 file changed, 70 insertions(+), 45 deletions(-)
>>>
>>> If somebody could provide an Ack on this patch, I'd really appreciate it,
>>> please. Whilst the portable ordering guarantees that I've documented are
>>> fairly conservative, I do think that this change is a big improvement and
>>> gives you what you need if you're writing a portable device driver for a new
>>> piece of hardware. I'm tackling the removal of MMIOWB as a separate series.
>>>
>>> I think Paul now requires an Ack before he'll send a patch to mainline,
>>> hence the grovelling.
>>
>> I'm afraid I'm not that qualified to provide an Ack to this patch,
>> but please find a nit fix below.
>
> Oh well, thanks for having a look anyway!
>
>>>> + (*) insX(), outsX():
>>>> +
>>>> + As above, the insX() and outX() accessors provide the same ordering
>> outsX()
>
> Thanks; I'll fix that.
>
>>>> + guarantees as readsX() and writesX() respectively when accessing a
>>>> mapping
>>>> + with the default I/O attributes.
>>>>
>>>> (*) ioreadX(), iowriteX()
>>>>
>>>> These will perform appropriately for the type of access they're
>>>> actually
>>>> doing, be it inX()/outX() or readX()/writeX().
>>>>
>>>> +All of these accessors assume that the underlying peripheral is
>>>> little-endian,
>>>> +and will therefore perform byte-swapping operations on big-endian
>>>> architectures.
>>>> +
>>>> +Composing I/O ordering barriers with SMP ordering barriers and LOCK/UNLOCK
>>>> +operations is a dangerous sport which may require the use of mmiowb().
>>>> See the
>>>> +subsection "Acquires vs I/O accesses" for more information.
>>>>
>>>>
>>>> ASSUMED MINIMUM EXECUTION ORDERING MODEL
>>>> --
>>>> 2.17.1
>>>>
>>
>> JFYI, there is another document Documentation/driver-api/device-io.rst,
>> which is somewhat related to this update. It looks like this one also needs
>> some update, as Jon commented in transforming to .rst format in commit
>> 8a8a602fdb83 ("docs: Convert the deviceio template to RST"):
>>
>> Like the rest of our documentation, this one could use some work.
>> There's
>> no mention of ioremap() and friends, no mention of io_read*() and
>> friends.
>> But we have nice documentation for all those folks writing new drivers
>> that
>> do port I/O :).
>>
>>
>> This commit was merged in v4.11 cycle. And there has been no update
>> whatsoever
>> since. mmiowb() is lightly mentioned therein. IMHO, just updating
>> memory-barriers.txt would widen the gap of information.
>>
>> Thoughts?
>
> I have a subsequent patch which kills mmiowb() entirely:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/mmiowb=3c1a2050c08fb8193777b60b49e60320254a156c
>
> and that one does hit device-io.rst.
Ah, I see.
So can somebody else have a look at this patch and provide an Ack, please?
Thanks, Akira
>
> Will
>
Re: [PATCH tip/core/rcu 04/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
Hi Will, On Tue, 2 Apr 2019 14:03:46 +0100, Will Deacon wrote: > On Tue, Mar 26, 2019 at 04:41:16PM -0700, Paul E. McKenney wrote: >> From: Will Deacon >> >> The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt is vague, >> x86-centric, out-of-date, incomplete and demonstrably incorrect in places. >> This is largely because I/O ordering is a horrible can of worms, but also >> because the document has stagnated as our understanding has evolved. >> >> Attempt to address some of that, by rewriting the section based on >> recent(-ish) discussions with Arnd, BenH and others. Maybe one day we'll >> find a way to formalise this stuff, but for now let's at least try to >> make the English easier to understand. >> >> Cc: "Paul E. McKenney" >> Cc: Benjamin Herrenschmidt >> Cc: Michael Ellerman >> Cc: Arnd Bergmann >> Cc: Peter Zijlstra >> Cc: Andrea Parri >> Cc: Palmer Dabbelt >> Cc: Daniel Lustig >> Cc: David Howells >> Cc: Alan Stern >> Cc: Linus Torvalds >> Cc: "Maciej W. Rozycki" >> Cc: Mikulas Patocka >> Signed-off-by: Will Deacon >> Signed-off-by: Paul E. McKenney >> --- >> Documentation/memory-barriers.txt | 115 ++ >> 1 file changed, 70 insertions(+), 45 deletions(-) > > If somebody could provide an Ack on this patch, I'd really appreciate it, > please. Whilst the portable ordering guarantees that I've documented are > fairly conservative, I do think that this change is a big improvement and > gives you what you need if you're writing a portable device driver for a new > piece of hardware. I'm tackling the removal of MMIOWB as a separate series. > > I think Paul now requires an Ack before he'll send a patch to mainline, > hence the grovelling. I'm afraid I'm not that qualified to provide an Ack to this patch, but please find a nit fix below. > > Cheers, > > Will > >> diff --git a/Documentation/memory-barriers.txt >> b/Documentation/memory-barriers.txt >> index 1c22b21ae922..158947ae78c2 100644 >> --- a/Documentation/memory-barriers.txt >> +++ b/Documentation/memory-barriers.txt >> @@ -2599,72 +2599,97 @@ likely, then interrupt-disabling locks should be >> used to guarantee ordering. >> KERNEL I/O BARRIER EFFECTS >> == >> >> -When accessing I/O memory, drivers should use the appropriate accessor >> -functions: >> +Interfacing with peripherals via I/O accesses is deeply architecture and >> device >> +specific. Therefore, drivers which are inherently non-portable may rely on >> +specific behaviours of their target systems in order to achieve >> synchronization >> +in the most lightweight manner possible. For drivers intending to be >> portable >> +between multiple architectures and bus implementations, the kernel offers a >> +series of accessor functions that provide various degrees of ordering >> +guarantees: >> >> - (*) inX(), outX(): >> + (*) readX(), writeX(): >> >> - These are intended to talk to I/O space rather than memory space, but >> - that's primarily a CPU-specific concept. The i386 and x86_64 >> processors >> - do indeed have special I/O space access cycles and instructions, but >> many >> - CPUs don't have such a concept. >> + The readX() and writeX() MMIO accessors take a pointer to the >> peripheral >> + being accessed as an __iomem * parameter. For pointers mapped with the >> + default I/O attributes (e.g. those returned by ioremap()), then the >> + ordering guarantees are as follows: >> >> - The PCI bus, amongst others, defines an I/O space concept which - on >> such >> - CPUs as i386 and x86_64 - readily maps to the CPU's concept of I/O >> - space. However, it may also be mapped as a virtual I/O space in the >> CPU's >> - memory map, particularly on those CPUs that don't support alternate I/O >> - spaces. >> + 1. All readX() and writeX() accesses to the same peripheral are ordered >> +with respect to each other. For example, this ensures that MMIO >> register >> +writes by the CPU to a particular device will arrive in program order. >> >> - Accesses to this space may be fully synchronous (as on i386), but >> - intermediary bridges (such as the PCI host bridge) may not fully honour >> - that. >> + 2. A writeX() by the CPU to the peripheral will first wait for the >> +completion of all prior CPU writes to memory. For example, this >> ensures >> +that writes by the CPU to an outbound DMA buffer allocated by >> +dma_alloc_coherent() will be visible to a DMA engine when the CPU >> writes >> +to its MMIO control register to trigger the transfer. >> >> - They are guaranteed to be fully ordered with respect to each other. >> + 3. A readX() by the CPU from the peripheral will complete before any >> +subsequent CPU reads from memory can begin. For example, this ensures >> +that reads by the CPU from an incoming DMA buffer allocated by >> +
Re: [RFC PATCH] tools/memory-model: Remove (dep ; rfi) from ppo
On Tue, 26 Feb 2019 16:04:50 +0100, Peter Zijlstra wrote:
> On Tue, Feb 26, 2019 at 06:28:45AM -0800, Paul E. McKenney wrote:
>
>> Yes, this all is a bit on the insane side from a kernel viewpoint.
>> But the paper you found does not impose this; it has instead been there
>> for about 20 years, back before C and C++ admitted to the existence
>> of concurrency. But of course compilers are getting more aggressive,
>> and yes, some of the problems show up in single-threaded code.
>
> But that paper is from last year!! It has Peter Sewell on, I'm sure he's
> heard of concurrency.
>
>> The usual response is "then cast the pointers to intptr_t!" but of
>> course that breaks type checking.
>
> I tried laundering the pointer through intptr_t, but I can't seem to
> unbreak it.
>
>
> root@ivb-ep:~/tmp# gcc-8 -O2 -fno-strict-aliasing -o ptr ptr.c ; ./ptr
> p=0x55aacdc80034 q=0x55aacdc80034
> x=1 y=2 *p=11 *q=2
> root@ivb-ep:~/tmp# cat ptr.c
> #include
> #include
> #include
> int y = 2, x = 1;
> int main (int argc, char **argv) {
> intptr_t P = (intptr_t)
> intptr_t Q = (intptr_t)
> P += sizeof(int);
> int *q =
> printf("p=%p q=%p\n", (int*)P, (int*)Q);
> if (P == Q) {
> int *p = (int *)P;
> *p = 11;
> printf("x=%d y=%d *p=%d *q=%d\n", x, y, *p, *q);
> }
> }
>
So, I'm looking at the macro RELOC_HIDE() defined in
include/linux/compiler-gcc.h.
It says:
/*
* This macro obfuscates arithmetic on a variable address so that gcc
* shouldn't recognize the original var, and make assumptions about it.
*
* This is needed because the C standard makes it undefined to do
* pointer arithmetic on "objects" outside their boundaries and the
* gcc optimizers assume this is the case. In particular they
* assume such arithmetic does not wrap.
*
[...]
*/
#define RELOC_HIDE(ptr, off)\
({ \
unsigned long __ptr;\
__asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
(typeof(ptr)) (__ptr + (off)); \
})
Looks like this macro has existed ever since the origin of Linus' git repo.
And the optimization "bug" discussed in this thread can be suppressed by
this macro.
For example,
$ gcc -O2 -o reloc_hide reloc_hide.c; ./reloc_hide
x=1 y=11 *p=11 *q=11
$ cat reloc_hide.c
#include
#include
#define RELOC_HIDE(ptr, off)\
({ \
uintptr_t __ptr;\
__asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
(typeof(ptr)) (__ptr + (off)); \
})
int y = 2, x = 1;
int main (int argc, char **argv) {
int *p = RELOC_HIDE(, sizeof(*p));
int *q = RELOC_HIDE(, 0);
if (p == q) {
*p = 11;
printf("x=%d y=%d *p=%d *q=%d\n", x, y, *p, *q);
}
}
Note that "uintptr_t" is used in this version of RELOC_HIDE() for user-land
code.
Am I the only one who was not aware of this gcc-specific macro?
Thanks, Akira
Re: [RFC PATCH] tools/memory-model: Remove (dep ; rfi) from ppo
Hello Peter, On Tue, 26 Feb 2019 14:49:06 +0100, Peter Zijlstra wrote: > On Tue, Feb 26, 2019 at 12:38:13PM +0100, Borislav Petkov wrote: >> On Tue, Feb 26, 2019 at 12:30:08PM +0100, Peter Zijlstra wrote: >>> When I used the argc variant, gcc-8 'works', but with s/argc/1/ it is >>> still broken. >> >> As requested on IRC: > > What I asked was if you could get your GCC developer friends to have a > look at this :-) > JFYI, there is a bugzilla ticket regarding this behavior of GCC at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502, which started on 13 June 2014 and the latest entry was on 02 Feb 2019. Thanks, Akira
Re: [RFC PATCH] tools/memory-model: Remove (dep ; rfi) from ppo
On Tue, 26 Feb 2019 07:04:27 -0800, Paul E. McKenney wrote: > On Tue, Feb 26, 2019 at 11:56:57PM +0900, Akira Yokosawa wrote: >> Hi Paul, >> >> On Tue, 26 Feb 2019 06:28:45 -0800, Paul E. McKenney wrote: >>> On Tue, Feb 26, 2019 at 02:49:06PM +0100, Peter Zijlstra wrote: >>>> On Tue, Feb 26, 2019 at 12:38:13PM +0100, Borislav Petkov wrote: >>>>> On Tue, Feb 26, 2019 at 12:30:08PM +0100, Peter Zijlstra wrote: >>>>>> When I used the argc variant, gcc-8 'works', but with s/argc/1/ it is >>>>>> still broken. >>>>> >>>>> As requested on IRC: >>>> >>>> What I asked was if you could get your GCC developer friends to have a >>>> look at this :-) >>> >>> Yes, this all is a bit on the insane side from a kernel viewpoint. >>> But the paper you found does not impose this; it has instead been there >>> for about 20 years, back before C and C++ admitted to the existence >>> of concurrency. >> >> By "it", do you mean the concept of "pointer provenance"? >> >> I'm asking because the paper's header reads: >> >> "ISO/IEC JTC1/SC22/WG14 N2311, 2018-11-09" >> >> Just wanted to make sure. > > This paper introduces neither pointer provenance nor indeterminate-on-free, > but rather proposes modification. These things have been around for a > few decades. Got it! Thank, Akira > > Thanx, Paul > >> Thanks, Akira >> >>> But of course compilers are getting more aggressive, >>> and yes, some of the problems show up in single-threaded code. >>> >>> The usual response is "then cast the pointers to intptr_t!" but of >>> course that breaks type checking. >>> >>> There is an effort to claw back the concurrency pieces, and I would >>> be happy to run the resulting paper past you guys. >>> >>> I must confess to not being all that sympathetic to code that takes >>> advantage of happenstance stack-frame layout. Is there some reason >>> we need that? >>> >>> Thanx, Paul >>> >> >
Re: [RFC PATCH] tools/memory-model: Remove (dep ; rfi) from ppo
Hi Paul, On Tue, 26 Feb 2019 06:28:45 -0800, Paul E. McKenney wrote: > On Tue, Feb 26, 2019 at 02:49:06PM +0100, Peter Zijlstra wrote: >> On Tue, Feb 26, 2019 at 12:38:13PM +0100, Borislav Petkov wrote: >>> On Tue, Feb 26, 2019 at 12:30:08PM +0100, Peter Zijlstra wrote: When I used the argc variant, gcc-8 'works', but with s/argc/1/ it is still broken. >>> >>> As requested on IRC: >> >> What I asked was if you could get your GCC developer friends to have a >> look at this :-) > > Yes, this all is a bit on the insane side from a kernel viewpoint. > But the paper you found does not impose this; it has instead been there > for about 20 years, back before C and C++ admitted to the existence > of concurrency. By "it", do you mean the concept of "pointer provenance"? I'm asking because the paper's header reads: "ISO/IEC JTC1/SC22/WG14 N2311, 2018-11-09" Just wanted to make sure. Thanks, Akira > But of course compilers are getting more aggressive, > and yes, some of the problems show up in single-threaded code. > > The usual response is "then cast the pointers to intptr_t!" but of > course that breaks type checking. > > There is an effort to claw back the concurrency pieces, and I would > be happy to run the resulting paper past you guys. > > I must confess to not being all that sympathetic to code that takes > advantage of happenstance stack-frame layout. Is there some reason > we need that? > > Thanx, Paul >
Re: [PATCH memory-model 0/3] Updates to the formal memory model
On 2018/12/03 15:51:27 -0800, Paul E. McKenney wrote: > On Tue, Dec 04, 2018 at 08:28:03AM +0900, Akira Yokosawa wrote: >> On 2018/12/03 15:04:11 -0800, Paul E. McKenney wrote: >>> Hello, Ingo! >>> >>> This series contains updates to the Linux kernel's formal memory model >>> in tools/memory-model. These patches are ready for inclusion into -tip. >>> >>> 1. Model smp_mb__after_unlock_lock(), courtesy of Andrea Parri. >>> >>> 2. Add scripts to check github litmus tests. >>> >>> 3. Make scripts take "-j" abbreviation for "--jobs". >>> >>> There is another series in preparation to model SRCU, but this series >>> requires hot-off-the presses changes to the herd tool that have not yet >>> been released. This SRCU series is therefore targeting the merge window >>> after the upcoming one. People wishing to experiment with the prototype >>> SRCU model may obtain it from my -rcu tree at branch "dev", and use >>> a bleeding-edge herd7 built from https://github.com/herd/herdtools7/, >>> version 7.51+2(dev), which is (commit 10403b24070c) or later. >> >> On the master branch of herdtools7, SRCU support was added in version >> 7.51+4(dev), which is commit 6ec9da1f4d58, or later. > > It has been working for me with version 7.51+2(dev), but perhaps I > have just been getting lucky. It wouldn't be the first time! ;-) Sounds like you've been at the HEAD of topic branch "srcu". Thanks, Akira > > Thanx, Paul > >> Thanks, Akira >> >>> >>> Thanx, Paul >>> >>> >>> >>> .gitignore |1 >>> README |2 >>> linux-kernel.bell |3 >>> linux-kernel.cat |4 - >>> linux-kernel.def |1 >>> scripts/README | 70 ++ >>> scripts/checkalllitmus.sh | 53 +++-- >>> scripts/checkghlitmus.sh | 65 >>> scripts/checklitmus.sh | 74 +++ >>> scripts/checklitmushist.sh | 60 +++ >>> scripts/cmplitmushist.sh | 87 +++ >>> scripts/initlitmushist.sh | 68 + >>> scripts/judgelitmus.sh | 78 + >>> scripts/newlitmushist.sh | 61 +++ >>> scripts/parseargs.sh | 140 >>> - >>> scripts/runlitmushist.sh | 87 +++ >>> 16 files changed, 757 insertions(+), 97 deletions(-) >>> >> >
Re: [PATCH memory-model 0/3] Updates to the formal memory model
On 2018/12/03 15:51:27 -0800, Paul E. McKenney wrote: > On Tue, Dec 04, 2018 at 08:28:03AM +0900, Akira Yokosawa wrote: >> On 2018/12/03 15:04:11 -0800, Paul E. McKenney wrote: >>> Hello, Ingo! >>> >>> This series contains updates to the Linux kernel's formal memory model >>> in tools/memory-model. These patches are ready for inclusion into -tip. >>> >>> 1. Model smp_mb__after_unlock_lock(), courtesy of Andrea Parri. >>> >>> 2. Add scripts to check github litmus tests. >>> >>> 3. Make scripts take "-j" abbreviation for "--jobs". >>> >>> There is another series in preparation to model SRCU, but this series >>> requires hot-off-the presses changes to the herd tool that have not yet >>> been released. This SRCU series is therefore targeting the merge window >>> after the upcoming one. People wishing to experiment with the prototype >>> SRCU model may obtain it from my -rcu tree at branch "dev", and use >>> a bleeding-edge herd7 built from https://github.com/herd/herdtools7/, >>> version 7.51+2(dev), which is (commit 10403b24070c) or later. >> >> On the master branch of herdtools7, SRCU support was added in version >> 7.51+4(dev), which is commit 6ec9da1f4d58, or later. > > It has been working for me with version 7.51+2(dev), but perhaps I > have just been getting lucky. It wouldn't be the first time! ;-) Sounds like you've been at the HEAD of topic branch "srcu". Thanks, Akira > > Thanx, Paul > >> Thanks, Akira >> >>> >>> Thanx, Paul >>> >>> >>> >>> .gitignore |1 >>> README |2 >>> linux-kernel.bell |3 >>> linux-kernel.cat |4 - >>> linux-kernel.def |1 >>> scripts/README | 70 ++ >>> scripts/checkalllitmus.sh | 53 +++-- >>> scripts/checkghlitmus.sh | 65 >>> scripts/checklitmus.sh | 74 +++ >>> scripts/checklitmushist.sh | 60 +++ >>> scripts/cmplitmushist.sh | 87 +++ >>> scripts/initlitmushist.sh | 68 + >>> scripts/judgelitmus.sh | 78 + >>> scripts/newlitmushist.sh | 61 +++ >>> scripts/parseargs.sh | 140 >>> - >>> scripts/runlitmushist.sh | 87 +++ >>> 16 files changed, 757 insertions(+), 97 deletions(-) >>> >> >
Re: [PATCH memory-model 0/3] Updates to the formal memory model
On 2018/12/03 15:04:11 -0800, Paul E. McKenney wrote: > Hello, Ingo! > > This series contains updates to the Linux kernel's formal memory model > in tools/memory-model. These patches are ready for inclusion into -tip. > > 1.Model smp_mb__after_unlock_lock(), courtesy of Andrea Parri. > > 2.Add scripts to check github litmus tests. > > 3.Make scripts take "-j" abbreviation for "--jobs". > > There is another series in preparation to model SRCU, but this series > requires hot-off-the presses changes to the herd tool that have not yet > been released. This SRCU series is therefore targeting the merge window > after the upcoming one. People wishing to experiment with the prototype > SRCU model may obtain it from my -rcu tree at branch "dev", and use > a bleeding-edge herd7 built from https://github.com/herd/herdtools7/, > version 7.51+2(dev), which is (commit 10403b24070c) or later. On the master branch of herdtools7, SRCU support was added in version 7.51+4(dev), which is commit 6ec9da1f4d58, or later. Thanks, Akira > > Thanx, Paul > > > > .gitignore |1 > README |2 > linux-kernel.bell |3 > linux-kernel.cat |4 - > linux-kernel.def |1 > scripts/README | 70 ++ > scripts/checkalllitmus.sh | 53 +++-- > scripts/checkghlitmus.sh | 65 > scripts/checklitmus.sh | 74 +++ > scripts/checklitmushist.sh | 60 +++ > scripts/cmplitmushist.sh | 87 +++ > scripts/initlitmushist.sh | 68 + > scripts/judgelitmus.sh | 78 + > scripts/newlitmushist.sh | 61 +++ > scripts/parseargs.sh | 140 > - > scripts/runlitmushist.sh | 87 +++ > 16 files changed, 757 insertions(+), 97 deletions(-) >
Re: [PATCH memory-model 0/3] Updates to the formal memory model
On 2018/12/03 15:04:11 -0800, Paul E. McKenney wrote: > Hello, Ingo! > > This series contains updates to the Linux kernel's formal memory model > in tools/memory-model. These patches are ready for inclusion into -tip. > > 1.Model smp_mb__after_unlock_lock(), courtesy of Andrea Parri. > > 2.Add scripts to check github litmus tests. > > 3.Make scripts take "-j" abbreviation for "--jobs". > > There is another series in preparation to model SRCU, but this series > requires hot-off-the presses changes to the herd tool that have not yet > been released. This SRCU series is therefore targeting the merge window > after the upcoming one. People wishing to experiment with the prototype > SRCU model may obtain it from my -rcu tree at branch "dev", and use > a bleeding-edge herd7 built from https://github.com/herd/herdtools7/, > version 7.51+2(dev), which is (commit 10403b24070c) or later. On the master branch of herdtools7, SRCU support was added in version 7.51+4(dev), which is commit 6ec9da1f4d58, or later. Thanks, Akira > > Thanx, Paul > > > > .gitignore |1 > README |2 > linux-kernel.bell |3 > linux-kernel.cat |4 - > linux-kernel.def |1 > scripts/README | 70 ++ > scripts/checkalllitmus.sh | 53 +++-- > scripts/checkghlitmus.sh | 65 > scripts/checklitmus.sh | 74 +++ > scripts/checklitmushist.sh | 60 +++ > scripts/cmplitmushist.sh | 87 +++ > scripts/initlitmushist.sh | 68 + > scripts/judgelitmus.sh | 78 + > scripts/newlitmushist.sh | 61 +++ > scripts/parseargs.sh | 140 > - > scripts/runlitmushist.sh | 87 +++ > 16 files changed, 757 insertions(+), 97 deletions(-) >
Re: [PATCH 0/3] tools/memory-model: Add SRCU support
On 2018/11/27 09:17:46 -0800, Paul E. McKenney wrote: > On Tue, Nov 27, 2018 at 01:26:42AM +0100, Andrea Parri wrote: >>> commit 72f61917f12236514a70017d1ebafb9b8d34a9b6 >>> Author: Paul E. McKenney >>> Date: Mon Nov 26 14:26:43 2018 -0800 >>> >>> tools/memory-model: Update README for addition of SRCU >>> >>> This commit updates the section on LKMM limitations to no longer say >>> that SRCU is not modeled, but instead describe how LKMM's modeling of >>> SRCU departs from the Linux-kernel implementation. >>> >>> TL;DR: There is no known valid use case that cares about the Linux >>> kernel's ability to have partially overlapping SRCU read-side critical >>> sections. >>> >>> Signed-off-by: Paul E. McKenney >> >> Indeed!, >> >> Acked-by: Andrea Parri > > Thank you, applied! > > I moved this commit and Alan's three SRCU commits to the branch destined > for the upcoming merge window. We need to bump the version of herdtools7 in "REQUIREMENTS". Would it be 7.52? Removing the explicit version number might be a better idea. Just say "The latest version of ...". Thoughts? Thanks, Akira > > Thanx, Paul > >> Andrea >> >> >>> >>> diff --git a/tools/memory-model/README b/tools/memory-model/README >>> index 0f2c366518c6..9d7d4f23503f 100644 >>> --- a/tools/memory-model/README >>> +++ b/tools/memory-model/README >>> @@ -221,8 +221,29 @@ The Linux-kernel memory model has the following >>> limitations: >>> additional call_rcu() process to the site of the >>> emulated rcu-barrier(). >>> >>> - e. Sleepable RCU (SRCU) is not modeled. It can be >>> - emulated, but perhaps not simply. >>> + e. Although sleepable RCU (SRCU) is now modeled, there >>> + are some subtle differences between its semantics and >>> + those in the Linux kernel. For example, the kernel >>> + might interpret the following sequence as two partially >>> + overlapping SRCU read-side critical sections: >>> + >>> +1 r1 = srcu_read_lock(_srcu); >>> +2 do_something_1(); >>> +3 r2 = srcu_read_lock(_srcu); >>> +4 do_something_2(); >>> +5 srcu_read_unlock(_srcu, r1); >>> +6 do_something_3(); >>> +7 srcu_read_unlock(_srcu, r2); >>> + >>> + In contrast, LKMM will interpret this as a nested pair of >>> + SRCU read-side critical sections, with the outer critical >>> + section spanning lines 1-7 and the inner critical section >>> + spanning lines 3-5. >>> + >>> + This difference would be more of a concern had anyone >>> + identified a reasonable use case for partially overlapping >>> + SRCU read-side critical sections. For more information, >>> + please see: https://paulmck.livejournal.com/40593.html >>> >>> f. Reader-writer locking is not modeled. It can be >>> emulated in litmus tests using atomic read-modify-write >>> >> >
Re: [PATCH 0/3] tools/memory-model: Add SRCU support
On 2018/11/27 09:17:46 -0800, Paul E. McKenney wrote: > On Tue, Nov 27, 2018 at 01:26:42AM +0100, Andrea Parri wrote: >>> commit 72f61917f12236514a70017d1ebafb9b8d34a9b6 >>> Author: Paul E. McKenney >>> Date: Mon Nov 26 14:26:43 2018 -0800 >>> >>> tools/memory-model: Update README for addition of SRCU >>> >>> This commit updates the section on LKMM limitations to no longer say >>> that SRCU is not modeled, but instead describe how LKMM's modeling of >>> SRCU departs from the Linux-kernel implementation. >>> >>> TL;DR: There is no known valid use case that cares about the Linux >>> kernel's ability to have partially overlapping SRCU read-side critical >>> sections. >>> >>> Signed-off-by: Paul E. McKenney >> >> Indeed!, >> >> Acked-by: Andrea Parri > > Thank you, applied! > > I moved this commit and Alan's three SRCU commits to the branch destined > for the upcoming merge window. We need to bump the version of herdtools7 in "REQUIREMENTS". Would it be 7.52? Removing the explicit version number might be a better idea. Just say "The latest version of ...". Thoughts? Thanks, Akira > > Thanx, Paul > >> Andrea >> >> >>> >>> diff --git a/tools/memory-model/README b/tools/memory-model/README >>> index 0f2c366518c6..9d7d4f23503f 100644 >>> --- a/tools/memory-model/README >>> +++ b/tools/memory-model/README >>> @@ -221,8 +221,29 @@ The Linux-kernel memory model has the following >>> limitations: >>> additional call_rcu() process to the site of the >>> emulated rcu-barrier(). >>> >>> - e. Sleepable RCU (SRCU) is not modeled. It can be >>> - emulated, but perhaps not simply. >>> + e. Although sleepable RCU (SRCU) is now modeled, there >>> + are some subtle differences between its semantics and >>> + those in the Linux kernel. For example, the kernel >>> + might interpret the following sequence as two partially >>> + overlapping SRCU read-side critical sections: >>> + >>> +1 r1 = srcu_read_lock(_srcu); >>> +2 do_something_1(); >>> +3 r2 = srcu_read_lock(_srcu); >>> +4 do_something_2(); >>> +5 srcu_read_unlock(_srcu, r1); >>> +6 do_something_3(); >>> +7 srcu_read_unlock(_srcu, r2); >>> + >>> + In contrast, LKMM will interpret this as a nested pair of >>> + SRCU read-side critical sections, with the outer critical >>> + section spanning lines 1-7 and the inner critical section >>> + spanning lines 3-5. >>> + >>> + This difference would be more of a concern had anyone >>> + identified a reasonable use case for partially overlapping >>> + SRCU read-side critical sections. For more information, >>> + please see: https://paulmck.livejournal.com/40593.html >>> >>> f. Reader-writer locking is not modeled. It can be >>> emulated in litmus tests using atomic read-modify-write >>> >> >
Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
On 2018/09/06 0:00, Andrea Parri wrote: > On Wed, Sep 05, 2018 at 11:33:08PM +0900, Akira Yokosawa wrote: >> On 2018/09/05 09:21:51 +0200, Andrea Parri wrote: >>> On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote: >>>> On Tue, 4 Sep 2018, Andrea Parri wrote: >>>>> Heh, your confusion might be the reflection of mine... ;-) That was >>>>> indeed a long and not conclusive discussion (meaning there're pending >>>>> issues); and I cannot claim to find "arguments" such as: >>>>> >>>>> "More than one kernel developer has expressed the opinion that >>>>>the LKMM should enforce ordering of writes by locking." >>>>> >>>>> particularly helpful (I do tend to be convinced by arguments rather >>>>> than by opinions). In fact, you can take the following as my only >>>>> current "constructive argument" against the patch [1,2]: >>>>> >>>>> THE COMMIT MESSAGE IS RIDICULOUS; PLEASE EXPAND ON IT, AND DO >>>>> SO BY LEVERAGING BOTH PROS AND CONS OF THE APPLIED CHANGES >>>> >>>> Do you have any concrete suggestions (i.e., some actual text) for >>>> improvements to the patch description? Earlier in your message you >>>> mentioned that Will's comment: >>>> >>>>LKMM offers stronger guarantees that can portably be relied upon >>>>in the codebase. >>>> >>>> would make a good addition. Suitably edited, it could be added to the >>>> description. I can think of a few other things myself, but I'd like to >>>> hear your thoughts. Anything else? >>> >>> Yes: I do sometimes have the impression that your "rules" for trimming >>> text in emails/replies are too aggressive... >> >> Andrea, by saying "Yes:", do you mean you have something else to be added? > > Indeed (examples in the trimmed text). So, you mean just amending commit log does not work for you? > > >> I don't think you do, but want to make sure. >> >> I'm a bit surprised to see all you wanted was the amendment of the >> commit log... > > Well, I said that it was my only current constructive argument... This thread is getting quite hard for me to follow... Akira > > Andrea > > >> >> Akira >> >>> >>> Andrea >>> >>> >>>> >>>> Alan >>>> >>
Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
On 2018/09/06 0:00, Andrea Parri wrote: > On Wed, Sep 05, 2018 at 11:33:08PM +0900, Akira Yokosawa wrote: >> On 2018/09/05 09:21:51 +0200, Andrea Parri wrote: >>> On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote: >>>> On Tue, 4 Sep 2018, Andrea Parri wrote: >>>>> Heh, your confusion might be the reflection of mine... ;-) That was >>>>> indeed a long and not conclusive discussion (meaning there're pending >>>>> issues); and I cannot claim to find "arguments" such as: >>>>> >>>>> "More than one kernel developer has expressed the opinion that >>>>>the LKMM should enforce ordering of writes by locking." >>>>> >>>>> particularly helpful (I do tend to be convinced by arguments rather >>>>> than by opinions). In fact, you can take the following as my only >>>>> current "constructive argument" against the patch [1,2]: >>>>> >>>>> THE COMMIT MESSAGE IS RIDICULOUS; PLEASE EXPAND ON IT, AND DO >>>>> SO BY LEVERAGING BOTH PROS AND CONS OF THE APPLIED CHANGES >>>> >>>> Do you have any concrete suggestions (i.e., some actual text) for >>>> improvements to the patch description? Earlier in your message you >>>> mentioned that Will's comment: >>>> >>>>LKMM offers stronger guarantees that can portably be relied upon >>>>in the codebase. >>>> >>>> would make a good addition. Suitably edited, it could be added to the >>>> description. I can think of a few other things myself, but I'd like to >>>> hear your thoughts. Anything else? >>> >>> Yes: I do sometimes have the impression that your "rules" for trimming >>> text in emails/replies are too aggressive... >> >> Andrea, by saying "Yes:", do you mean you have something else to be added? > > Indeed (examples in the trimmed text). So, you mean just amending commit log does not work for you? > > >> I don't think you do, but want to make sure. >> >> I'm a bit surprised to see all you wanted was the amendment of the >> commit log... > > Well, I said that it was my only current constructive argument... This thread is getting quite hard for me to follow... Akira > > Andrea > > >> >> Akira >> >>> >>> Andrea >>> >>> >>>> >>>> Alan >>>> >>
Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
On 2018/09/05 09:21:51 +0200, Andrea Parri wrote: > On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote: >> On Tue, 4 Sep 2018, Andrea Parri wrote: >>> Heh, your confusion might be the reflection of mine... ;-) That was >>> indeed a long and not conclusive discussion (meaning there're pending >>> issues); and I cannot claim to find "arguments" such as: >>> >>> "More than one kernel developer has expressed the opinion that >>>the LKMM should enforce ordering of writes by locking." >>> >>> particularly helpful (I do tend to be convinced by arguments rather >>> than by opinions). In fact, you can take the following as my only >>> current "constructive argument" against the patch [1,2]: >>> >>> THE COMMIT MESSAGE IS RIDICULOUS; PLEASE EXPAND ON IT, AND DO >>> SO BY LEVERAGING BOTH PROS AND CONS OF THE APPLIED CHANGES >> >> Do you have any concrete suggestions (i.e., some actual text) for >> improvements to the patch description? Earlier in your message you >> mentioned that Will's comment: >> >> LKMM offers stronger guarantees that can portably be relied upon >> in the codebase. >> >> would make a good addition. Suitably edited, it could be added to the >> description. I can think of a few other things myself, but I'd like to >> hear your thoughts. Anything else? > > Yes: I do sometimes have the impression that your "rules" for trimming > text in emails/replies are too aggressive... Andrea, by saying "Yes:", do you mean you have something else to be added? I don't think you do, but want to make sure. I'm a bit surprised to see all you wanted was the amendment of the commit log... Akira > > Andrea > > >> >> Alan >>
Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
On 2018/09/05 09:21:51 +0200, Andrea Parri wrote: > On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote: >> On Tue, 4 Sep 2018, Andrea Parri wrote: >>> Heh, your confusion might be the reflection of mine... ;-) That was >>> indeed a long and not conclusive discussion (meaning there're pending >>> issues); and I cannot claim to find "arguments" such as: >>> >>> "More than one kernel developer has expressed the opinion that >>>the LKMM should enforce ordering of writes by locking." >>> >>> particularly helpful (I do tend to be convinced by arguments rather >>> than by opinions). In fact, you can take the following as my only >>> current "constructive argument" against the patch [1,2]: >>> >>> THE COMMIT MESSAGE IS RIDICULOUS; PLEASE EXPAND ON IT, AND DO >>> SO BY LEVERAGING BOTH PROS AND CONS OF THE APPLIED CHANGES >> >> Do you have any concrete suggestions (i.e., some actual text) for >> improvements to the patch description? Earlier in your message you >> mentioned that Will's comment: >> >> LKMM offers stronger guarantees that can portably be relied upon >> in the codebase. >> >> would make a good addition. Suitably edited, it could be added to the >> description. I can think of a few other things myself, but I'd like to >> hear your thoughts. Anything else? > > Yes: I do sometimes have the impression that your "rules" for trimming > text in emails/replies are too aggressive... Andrea, by saying "Yes:", do you mean you have something else to be added? I don't think you do, but want to make sure. I'm a bit surprised to see all you wanted was the amendment of the commit log... Akira > > Andrea > > >> >> Alan >>
Re: [PATCH 0/2] tools/memory-model: remove ACCESS_ONCE()
On 2018/06/28 08:21:40 -0700, Paul E. McKenney wrote: [...] > > While I am at it, here is the current scorecard: > > e9ff68680cd4 tools/memory-model: Add litmus test for full multicopy atomicity > c21fcc6594f1 tools/memory-model: Fix ISA2+pooncelock+pooncelock+pombonce name > aa838e0b70e1 MAINTAINERS: Add Daniel Lustig as an LKMM reviewer > 3cb0d7701c4c locking/memory-barriers.txt/kokr: Update Korean translation to > fix broken DMA vs. MMIO ordering example > 0bde941f3629 tools/memory-model: Remove ACCESS_ONCE() from recipes > 80b7b05c3aa0 tools/memory-model: Remove ACCESS_ONCE() from model > > The above patches are ready for the upcoming merge window because > each has at least one Acked-by or Reviewed-by. > > 6098ce88bc4d tools/memory-model: Make scripts executable In this commit, "Usage:" in the header of scripts/checklitmus.sh should also be updated. When it is fixed, Acked-by: Akira Yokosawa Thanks, Akira > 5bb22d0126f9 tools/memory-model: Rename litmus tests to comply to norm7 > 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation > > The above patches need at least one additional Acked-by > or Reviewed-by. If any of you gets a chance, please do > look them over. > > 51b0a8985c5a EXP tools/memory-model: Add litmus-test naming scheme > > This patch needs me to get Will Deacon's feedback applied. :-/ > > 06e99a0d9662 EXP tools/memory-model: Add .cfg and .cat files for s390 > > This is a placeholder, and probably won't ever go upstream > into the Linux kernel. (Maybe someday into herd where the > other architecture-specific .cat files live.) > > Thanx, Paul > >> Cheers, >> Andrea >> >> >>> >>> tools/memory-model/Documentation/recipes.txt | 4 ++-- >>> tools/memory-model/linux-kernel.bell | 2 +- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >>> >>> -- >>> 2.11.0 >>> >> >
Re: [PATCH 0/2] tools/memory-model: remove ACCESS_ONCE()
On 2018/06/28 08:21:40 -0700, Paul E. McKenney wrote: [...] > > While I am at it, here is the current scorecard: > > e9ff68680cd4 tools/memory-model: Add litmus test for full multicopy atomicity > c21fcc6594f1 tools/memory-model: Fix ISA2+pooncelock+pooncelock+pombonce name > aa838e0b70e1 MAINTAINERS: Add Daniel Lustig as an LKMM reviewer > 3cb0d7701c4c locking/memory-barriers.txt/kokr: Update Korean translation to > fix broken DMA vs. MMIO ordering example > 0bde941f3629 tools/memory-model: Remove ACCESS_ONCE() from recipes > 80b7b05c3aa0 tools/memory-model: Remove ACCESS_ONCE() from model > > The above patches are ready for the upcoming merge window because > each has at least one Acked-by or Reviewed-by. > > 6098ce88bc4d tools/memory-model: Make scripts executable In this commit, "Usage:" in the header of scripts/checklitmus.sh should also be updated. When it is fixed, Acked-by: Akira Yokosawa Thanks, Akira > 5bb22d0126f9 tools/memory-model: Rename litmus tests to comply to norm7 > 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation > > The above patches need at least one additional Acked-by > or Reviewed-by. If any of you gets a chance, please do > look them over. > > 51b0a8985c5a EXP tools/memory-model: Add litmus-test naming scheme > > This patch needs me to get Will Deacon's feedback applied. :-/ > > 06e99a0d9662 EXP tools/memory-model: Add .cfg and .cat files for s390 > > This is a placeholder, and probably won't ever go upstream > into the Linux kernel. (Maybe someday into herd where the > other architecture-specific .cat files live.) > > Thanx, Paul > >> Cheers, >> Andrea >> >> >>> >>> tools/memory-model/Documentation/recipes.txt | 4 ++-- >>> tools/memory-model/linux-kernel.bell | 2 +- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >>> >>> -- >>> 2.11.0 >>> >> >
[tip:locking/core] tools/memory-model: Update required version of herdtools7
Commit-ID: 5b62832c1e5284030500f82d6b3579ceed399fe6 Gitweb: https://git.kernel.org/tip/5b62832c1e5284030500f82d6b3579ceed399fe6 Author: Akira Yokosawa <aki...@gmail.com> AuthorDate: Mon, 14 May 2018 16:33:41 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-model: Update required version of herdtools7 Code generated by klitmus7 version 7.48 doesn't compile with kernel header of 4.15 and later due to the absence of ACCESS_ONCE(). As the issue has been resolved in herdtools7 7.49, bump the required version number in README. Signed-off-by: Akira Yokosawa <aki...@gmail.com> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com> Cc: Alan Stern <st...@rowland.harvard.edu> Cc: Andrea Parri <parri.and...@gmail.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Boqun Feng <boqun.f...@gmail.com> Cc: David Howells <dhowe...@redhat.com> Cc: Jade Alglave <j.algl...@ucl.ac.uk> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Luc Maranget <luc.maran...@inria.fr> Cc: Nicholas Piggin <npig...@gmail.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Will Deacon <will.dea...@arm.com> Cc: linux-a...@vger.kernel.org Link: http://lkml.kernel.org/r/1526340837-1-3-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mi...@kernel.org> --- tools/memory-model/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/README b/tools/memory-model/README index 0b3a5f3c9ccd..734f7feaa5dc 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -20,7 +20,7 @@ that litmus test to be exercised within the Linux kernel. REQUIREMENTS -Version 7.48 of the "herd7" and "klitmus7" tools must be downloaded +Version 7.49 of the "herd7" and "klitmus7" tools must be downloaded separately: https://github.com/herd/herdtools7
[tip:locking/core] tools/memory-model: Update required version of herdtools7
Commit-ID: 5b62832c1e5284030500f82d6b3579ceed399fe6 Gitweb: https://git.kernel.org/tip/5b62832c1e5284030500f82d6b3579ceed399fe6 Author: Akira Yokosawa AuthorDate: Mon, 14 May 2018 16:33:41 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-model: Update required version of herdtools7 Code generated by klitmus7 version 7.48 doesn't compile with kernel header of 4.15 and later due to the absence of ACCESS_ONCE(). As the issue has been resolved in herdtools7 7.49, bump the required version number in README. Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney Cc: Alan Stern Cc: Andrea Parri Cc: Andrew Morton Cc: Boqun Feng Cc: David Howells Cc: Jade Alglave Cc: Linus Torvalds Cc: Luc Maranget Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-a...@vger.kernel.org Link: http://lkml.kernel.org/r/1526340837-1-3-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/README b/tools/memory-model/README index 0b3a5f3c9ccd..734f7feaa5dc 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -20,7 +20,7 @@ that litmus test to be exercised within the Linux kernel. REQUIREMENTS -Version 7.48 of the "herd7" and "klitmus7" tools must be downloaded +Version 7.49 of the "herd7" and "klitmus7" tools must be downloaded separately: https://github.com/herd/herdtools7
[PATCH] tools/memory-model: Update required version of herdtools7
>From 64542a47acf159d26b8290480c0af9c2a05d20d6 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa <aki...@gmail.com> Date: Sun, 8 Apr 2018 07:44:55 +0900 Subject: [PATCH] tools/memory-model: Update required version of herdtools7 Code generated by klitmus7 version 7.48 doesn't compile with kernel header of 4.15 and later due to the absence of ACCESS_ONCE(). As the issue has been resolved in herdtools7 7.49, bump the required version number in README. Signed-off-by: Akira Yokosawa <aki...@gmail.com> Cc: Alan Stern <st...@rowland.harvard.edu> Cc: Andrea Parri <parri.and...@gmail.com> Cc: Will Deacon <will.dea...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Boqun Feng <boqun.f...@gmail.com> Cc: Nicholas Piggin <npig...@gmail.com> Cc: David Howells <dhowe...@redhat.com> Cc: Jade Alglave <j.algl...@ucl.ac.uk> Cc: Luc Maranget <luc.maran...@inria.fr> Cc: "Paul E. McKenney" <paul...@linux.vnet.ibm.com> Cc: Ingo Molnar <mi...@redhat.com> --- Hi Paul, I think this is a 4.17 matter. Thoughts? Thanks, Akira -- tools/memory-model/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/README b/tools/memory-model/README index 0b3a5f3..734f7fe 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -20,7 +20,7 @@ that litmus test to be exercised within the Linux kernel. REQUIREMENTS -Version 7.48 of the "herd7" and "klitmus7" tools must be downloaded +Version 7.49 of the "herd7" and "klitmus7" tools must be downloaded separately: https://github.com/herd/herdtools7 -- 2.7.4
[PATCH] tools/memory-model: Update required version of herdtools7
>From 64542a47acf159d26b8290480c0af9c2a05d20d6 Mon Sep 17 00:00:00 2001 From: Akira Yokosawa Date: Sun, 8 Apr 2018 07:44:55 +0900 Subject: [PATCH] tools/memory-model: Update required version of herdtools7 Code generated by klitmus7 version 7.48 doesn't compile with kernel header of 4.15 and later due to the absence of ACCESS_ONCE(). As the issue has been resolved in herdtools7 7.49, bump the required version number in README. Signed-off-by: Akira Yokosawa Cc: Alan Stern Cc: Andrea Parri 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: Ingo Molnar --- Hi Paul, I think this is a 4.17 matter. Thoughts? Thanks, Akira -- tools/memory-model/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/README b/tools/memory-model/README index 0b3a5f3..734f7fe 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -20,7 +20,7 @@ that litmus test to be exercised within the Linux kernel. REQUIREMENTS -Version 7.48 of the "herd7" and "klitmus7" tools must be downloaded +Version 7.49 of the "herd7" and "klitmus7" tools must be downloaded separately: https://github.com/herd/herdtools7 -- 2.7.4
Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/24 10:08:14 -0800, Paul E. McKenney wrote:
> On Sat, Feb 24, 2018 at 11:49:20AM -0500, Alan Stern wrote:
>> On Sat, 24 Feb 2018, Andrea Parri wrote:
>>
>>> On Fri, Feb 23, 2018 at 07:30:13PM -0800, Paul E. McKenney wrote:
>>>> On Sat, Feb 24, 2018 at 12:22:24PM +0900, Akira Yokosawa wrote:
>>>>> On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote:
>>>>>> On 2018/02/22 2:15, Alan Stern wrote:
>>>
>>> [...]
>>>
>>>>>>>
>>>>>>> Akira pointed out some typos in the original patch, and he noted that
>>>>>>> cheatsheet.txt should be updated to indicate how unsuccessful RMW
>>>>>>> operations relate to address dependencies.
>>>>>>
>>>>>> My point was to separate unannotated loads from READ_ONCE(), if the
>>>>>> cheatsheet should concern such accesses as well.
>>>>>> Unsuccessful RMW operations were brought up by Andrea.
>>>>>>
>>>>>
>>>>> Paul, can you amend above paragraph in the change log to something like:
>>>>>
>>>>> Akira pointed out some typos in the original patch, and he noted that
>>>>> cheatsheet.txt should be updated to indicate READ_ONCE() implies
>>>>> address dependency, which invited Andrea's observation that it should
>>>>> also be updated to indicate how unsuccessful RMW operations relate to
>>>>> address dependencies.
>>>>>
>>>>> , if Alan and Andrea are OK with the amendment.
>>>>>
>>>>> Also, please append my Acked-by.
>>>>>
>>>>> Acked-by: Akira Yokosawa <aki...@gmail.com>
>>>>
>>>> I can still amend this, and have added your Acked-by. If Alan and Andrea
>>>> OK with your change, I will apply that also.
>>>
>>> LGTM. Thanks,
>>
>> Me too.
>
> Very good, how about this for the new version?
>
> Thanx, Paul
>
>
>
> commit 21ede43970e50b7397420f17ed08bb02c187e2eb
> Author: Alan Stern <st...@rowland.harvard.edu>
> Date: Wed Feb 21 12:15:56 2018 -0500
>
> tools/memory-model: Update: Remove rb-dep, smp_read_barrier_depends, and
> lockless_dereference
>
> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference") was accidentally
> merged too early, while it was still in RFC form. This patch adds in
> the missing pieces.
>
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should indicate that READ_ONCE() now implies an address
> dependency. Andrea suggested documenting the relationship betwwen
> unsuccessful RMW operations and address dependencies.
Looks good. But I've found a remaining typo in the patch. See below.
> > Andrea pointed out that the macro for rcu_dereference() in linux.def
> should now use the "once" annotation instead of "deref". He also
> suggested that the comments should mention commit 5a8897cc7631
> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
> _release()/_relaxed() atomics") as an important precursor, and he
> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
> unconditional memory barrier to cmpxchg()"), another prerequisite.
>
> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
> Suggested-by: Akira Yokosawa <aki...@gmail.com>
> Suggested-by: Andrea Parri <parri.and...@gmail.com>
> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference")
> Acked-by: Andrea Parri <parri.and...@gmail.com>
> Acked-by: Akira Yokosawa <aki...@gmail.com>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
>
> diff --git a/tools/memory-model/Documentation/cheatsheet.txt
> b/tools/memory-model/Documentation/cheatsheet.txt
> index 04e458acd6d4..956b1ae4aafb 100644
> --- a/tools/memory-model/Documentation/cheatsheet.txt
> +++ b/tools/memory-model/Documentation/cheatsheet.txt
> @@ -1,11 +1,11 @@
>Prior Operation Subsequent Operation
>---
> ---
> C Self R W RWM Self R W DR DW RMW
> SV
> -
Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/24 10:08:14 -0800, Paul E. McKenney wrote:
> On Sat, Feb 24, 2018 at 11:49:20AM -0500, Alan Stern wrote:
>> On Sat, 24 Feb 2018, Andrea Parri wrote:
>>
>>> On Fri, Feb 23, 2018 at 07:30:13PM -0800, Paul E. McKenney wrote:
>>>> On Sat, Feb 24, 2018 at 12:22:24PM +0900, Akira Yokosawa wrote:
>>>>> On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote:
>>>>>> On 2018/02/22 2:15, Alan Stern wrote:
>>>
>>> [...]
>>>
>>>>>>>
>>>>>>> Akira pointed out some typos in the original patch, and he noted that
>>>>>>> cheatsheet.txt should be updated to indicate how unsuccessful RMW
>>>>>>> operations relate to address dependencies.
>>>>>>
>>>>>> My point was to separate unannotated loads from READ_ONCE(), if the
>>>>>> cheatsheet should concern such accesses as well.
>>>>>> Unsuccessful RMW operations were brought up by Andrea.
>>>>>>
>>>>>
>>>>> Paul, can you amend above paragraph in the change log to something like:
>>>>>
>>>>> Akira pointed out some typos in the original patch, and he noted that
>>>>> cheatsheet.txt should be updated to indicate READ_ONCE() implies
>>>>> address dependency, which invited Andrea's observation that it should
>>>>> also be updated to indicate how unsuccessful RMW operations relate to
>>>>> address dependencies.
>>>>>
>>>>> , if Alan and Andrea are OK with the amendment.
>>>>>
>>>>> Also, please append my Acked-by.
>>>>>
>>>>> Acked-by: Akira Yokosawa
>>>>
>>>> I can still amend this, and have added your Acked-by. If Alan and Andrea
>>>> OK with your change, I will apply that also.
>>>
>>> LGTM. Thanks,
>>
>> Me too.
>
> Very good, how about this for the new version?
>
> Thanx, Paul
>
>
>
> commit 21ede43970e50b7397420f17ed08bb02c187e2eb
> Author: Alan Stern
> Date: Wed Feb 21 12:15:56 2018 -0500
>
> tools/memory-model: Update: Remove rb-dep, smp_read_barrier_depends, and
> lockless_dereference
>
> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference") was accidentally
> merged too early, while it was still in RFC form. This patch adds in
> the missing pieces.
>
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should indicate that READ_ONCE() now implies an address
> dependency. Andrea suggested documenting the relationship betwwen
> unsuccessful RMW operations and address dependencies.
Looks good. But I've found a remaining typo in the patch. See below.
> > Andrea pointed out that the macro for rcu_dereference() in linux.def
> should now use the "once" annotation instead of "deref". He also
> suggested that the comments should mention commit 5a8897cc7631
> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
> _release()/_relaxed() atomics") as an important precursor, and he
> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
> unconditional memory barrier to cmpxchg()"), another prerequisite.
>
> Signed-off-by: Alan Stern
> Suggested-by: Akira Yokosawa
> Suggested-by: Andrea Parri
> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference")
> Acked-by: Andrea Parri
> Acked-by: Akira Yokosawa
> Signed-off-by: Paul E. McKenney
>
> diff --git a/tools/memory-model/Documentation/cheatsheet.txt
> b/tools/memory-model/Documentation/cheatsheet.txt
> index 04e458acd6d4..956b1ae4aafb 100644
> --- a/tools/memory-model/Documentation/cheatsheet.txt
> +++ b/tools/memory-model/Documentation/cheatsheet.txt
> @@ -1,11 +1,11 @@
>Prior Operation Subsequent Operation
>---
> ---
> C Self R W RWM Self R W DR DW RMW
> SV
> - __ - - --- - - -- -- ---
> --
> + -- - - --- - - -- -- ---
> --
>
> Store, e.g., WRITE_ONCE()
Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote:
> On 2018/02/22 2:15, Alan Stern wrote:
>> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
>> smp_read_barrier_depends, and lockless_dereference") was accidentally
>> merged too early, while it was still in RFC form. This patch adds in
>> the missing pieces.
>>
>> Akira pointed out some typos in the original patch, and he noted that
>> cheatsheet.txt should be updated to indicate how unsuccessful RMW
>> operations relate to address dependencies.
>
> My point was to separate unannotated loads from READ_ONCE(), if the
> cheatsheet should concern such accesses as well.
> Unsuccessful RMW operations were brought up by Andrea.
>
Paul, can you amend above paragraph in the change log to something like:
Akira pointed out some typos in the original patch, and he noted that
cheatsheet.txt should be updated to indicate READ_ONCE() implies
address dependency, which invited Andrea's observation that it should
also be updated to indicate how unsuccessful RMW operations relate to
address dependencies.
, if Alan and Andrea are OK with the amendment.
Also, please append my Acked-by.
Acked-by: Akira Yokosawa <aki...@gmail.com>
Thanks, Akira
>>
>> Andrea pointed out that the macro for rcu_dereference() in linux.def
>> should now use the "once" annotation instead of "deref". He also
>> suggested that the comments should mention commit 5a8897cc7631
>> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
>> _release()/_relaxed() atomics") as an important precursor, and he
>> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
>> unconditional memory barrier to cmpxchg()"), another prerequisite.
>>
>> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
>> Suggested-by: Akira Yokosawa <aki...@gmail.com>
>> Suggested-by: Andrea Parri <parri.and...@gmail.com>
>> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep,
>> smp_read_barrier_depends, and lockless_dereference")
>>
>
> The change itself looks good to me.
>
> Acked-by: Akira Yokosawa <aki...@gmail.com>
>
>Thanks, Akira
>
>> ---
>>
>> tools/memory-model/Documentation/cheatsheet.txt |6 +++---
>> tools/memory-model/Documentation/explanation.txt |4 ++--
>> tools/memory-model/linux-kernel.def |2 +-
>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> Index: usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
>> ===
>> --- usb-4.x.orig/tools/memory-model/Documentation/cheatsheet.txt
>> +++ usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
>> @@ -1,11 +1,11 @@
>>Prior Operation Subsequent Operation
>>---
>> ---
>> C Self R W RWM Self R W DR DW RMW
>> SV
>> - __ - - --- - - -- -- ---
>> --
>> + -- - - --- - - -- -- ---
>> --
>>
>> Store, e.g., WRITE_ONCE()Y
>> Y
>> -Load, e.g., READ_ONCE() Y Y
>> Y
>> -Unsuccessful RMW operation Y Y
>> Y
>> +Load, e.g., READ_ONCE() Y Y Y
>> Y
>> +Unsuccessful RMW operation Y Y Y
>> Y
>> rcu_dereference()Y Y Y
>> Y
>> Successful *_acquire() R Y Y Y YY
>> Y
>> Successful *_release() CY YY W
>> Y
>> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt
>> ===
>> --- usb-4.x.orig/tools/memory-model/Documentation/explanation.txt
>> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt
>> @@ -826,7 +826,7 @@ A-cumulative; they only affect the propa
>> executed on C before the fence (i.e., those which precede the fence in
>> program order).
>>
>> -read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
>> +read_read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
>>
Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote:
> On 2018/02/22 2:15, Alan Stern wrote:
>> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
>> smp_read_barrier_depends, and lockless_dereference") was accidentally
>> merged too early, while it was still in RFC form. This patch adds in
>> the missing pieces.
>>
>> Akira pointed out some typos in the original patch, and he noted that
>> cheatsheet.txt should be updated to indicate how unsuccessful RMW
>> operations relate to address dependencies.
>
> My point was to separate unannotated loads from READ_ONCE(), if the
> cheatsheet should concern such accesses as well.
> Unsuccessful RMW operations were brought up by Andrea.
>
Paul, can you amend above paragraph in the change log to something like:
Akira pointed out some typos in the original patch, and he noted that
cheatsheet.txt should be updated to indicate READ_ONCE() implies
address dependency, which invited Andrea's observation that it should
also be updated to indicate how unsuccessful RMW operations relate to
address dependencies.
, if Alan and Andrea are OK with the amendment.
Also, please append my Acked-by.
Acked-by: Akira Yokosawa
Thanks, Akira
>>
>> Andrea pointed out that the macro for rcu_dereference() in linux.def
>> should now use the "once" annotation instead of "deref". He also
>> suggested that the comments should mention commit 5a8897cc7631
>> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
>> _release()/_relaxed() atomics") as an important precursor, and he
>> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
>> unconditional memory barrier to cmpxchg()"), another prerequisite.
>>
>> Signed-off-by: Alan Stern
>> Suggested-by: Akira Yokosawa
>> Suggested-by: Andrea Parri
>> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep,
>> smp_read_barrier_depends, and lockless_dereference")
>>
>
> The change itself looks good to me.
>
> Acked-by: Akira Yokosawa
>
>Thanks, Akira
>
>> ---
>>
>> tools/memory-model/Documentation/cheatsheet.txt |6 +++---
>> tools/memory-model/Documentation/explanation.txt |4 ++--
>> tools/memory-model/linux-kernel.def |2 +-
>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> Index: usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
>> ===
>> --- usb-4.x.orig/tools/memory-model/Documentation/cheatsheet.txt
>> +++ usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
>> @@ -1,11 +1,11 @@
>>Prior Operation Subsequent Operation
>>---
>> ---
>> C Self R W RWM Self R W DR DW RMW
>> SV
>> - __ - - --- - - -- -- ---
>> --
>> + -- - - --- - - -- -- ---
>> --
>>
>> Store, e.g., WRITE_ONCE()Y
>> Y
>> -Load, e.g., READ_ONCE() Y Y
>> Y
>> -Unsuccessful RMW operation Y Y
>> Y
>> +Load, e.g., READ_ONCE() Y Y Y
>> Y
>> +Unsuccessful RMW operation Y Y Y
>> Y
>> rcu_dereference()Y Y Y
>> Y
>> Successful *_acquire() R Y Y Y YY
>> Y
>> Successful *_release() CY YY W
>> Y
>> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt
>> ===
>> --- usb-4.x.orig/tools/memory-model/Documentation/explanation.txt
>> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt
>> @@ -826,7 +826,7 @@ A-cumulative; they only affect the propa
>> executed on C before the fence (i.e., those which precede the fence in
>> program order).
>>
>> -read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
>> +read_read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
>> other properties which we discuss later.
>>
>>
>> @@ -1138,7 +1138,7 @@ final effect is that even though the two
>> program order, it appears that they aren't.
&g
Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/22 2:15, Alan Stern wrote:
> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference") was accidentally
> merged too early, while it was still in RFC form. This patch adds in
> the missing pieces.
>
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should be updated to indicate how unsuccessful RMW
> operations relate to address dependencies.
My point was to separate unannotated loads from READ_ONCE(), if the
cheatsheet should concern such accesses as well.
Unsuccessful RMW operations were brought up by Andrea.
>
> Andrea pointed out that the macro for rcu_dereference() in linux.def
> should now use the "once" annotation instead of "deref". He also
> suggested that the comments should mention commit 5a8897cc7631
> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
> _release()/_relaxed() atomics") as an important precursor, and he
> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
> unconditional memory barrier to cmpxchg()"), another prerequisite.
>
> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
> Suggested-by: Akira Yokosawa <aki...@gmail.com>
> Suggested-by: Andrea Parri <parri.and...@gmail.com>
> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference")
>
The change itself looks good to me.
Acked-by: Akira Yokosawa <aki...@gmail.com>
Thanks, Akira
> ---
>
> tools/memory-model/Documentation/cheatsheet.txt |6 +++---
> tools/memory-model/Documentation/explanation.txt |4 ++--
> tools/memory-model/linux-kernel.def |2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> Index: usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
> ===
> --- usb-4.x.orig/tools/memory-model/Documentation/cheatsheet.txt
> +++ usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
> @@ -1,11 +1,11 @@
>Prior Operation Subsequent Operation
>---
> ---
> C Self R W RWM Self R W DR DW RMW
> SV
> - __ - - --- - - -- -- ---
> --
> + -- - - --- - - -- -- ---
> --
>
> Store, e.g., WRITE_ONCE()Y
> Y
> -Load, e.g., READ_ONCE() Y Y
> Y
> -Unsuccessful RMW operation Y Y
> Y
> +Load, e.g., READ_ONCE() Y Y Y
> Y
> +Unsuccessful RMW operation Y Y Y
> Y
> rcu_dereference()Y Y Y
> Y
> Successful *_acquire() R Y Y Y YY
> Y
> Successful *_release() CY YY W
> Y
> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt
> ===
> --- usb-4.x.orig/tools/memory-model/Documentation/explanation.txt
> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt
> @@ -826,7 +826,7 @@ A-cumulative; they only affect the propa
> executed on C before the fence (i.e., those which precede the fence in
> program order).
>
> -read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
> +read_read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
> other properties which we discuss later.
>
>
> @@ -1138,7 +1138,7 @@ final effect is that even though the two
> program order, it appears that they aren't.
>
> This could not have happened if the local cache had processed the
> -incoming stores in FIFO order. In constrast, other architectures
> +incoming stores in FIFO order. By contrast, other architectures
> maintain at least the appearance of FIFO order.
>
> In practice, this difficulty is solved by inserting a special fence
> Index: usb-4.x/tools/memory-model/linux-kernel.def
> ===
> --- usb-4.x.orig/tools/memory-model/linux-kernel.def
> +++ usb-4.x/tools/memory-model/linux-kernel.def
> @@ -13,7 +13,7 @@ WRITE_ONCE(X,V) { __store{once}(X,V); }
> smp_store_release(X,V) { __store{release}(*X,V); }
> smp_load_acquire(X) __load{acquire}(*X)
> rcu_assign_pointer(X,V) { __store{release}(X,V); }
> -rcu_dereference(X) __load{deref}(X)
> +rcu_dereference(X) __load{once}(X)
>
> // Fences
> smp_mb() { __fence{mb} ; }
>
Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/22 2:15, Alan Stern wrote:
> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference") was accidentally
> merged too early, while it was still in RFC form. This patch adds in
> the missing pieces.
>
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should be updated to indicate how unsuccessful RMW
> operations relate to address dependencies.
My point was to separate unannotated loads from READ_ONCE(), if the
cheatsheet should concern such accesses as well.
Unsuccessful RMW operations were brought up by Andrea.
>
> Andrea pointed out that the macro for rcu_dereference() in linux.def
> should now use the "once" annotation instead of "deref". He also
> suggested that the comments should mention commit 5a8897cc7631
> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
> _release()/_relaxed() atomics") as an important precursor, and he
> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
> unconditional memory barrier to cmpxchg()"), another prerequisite.
>
> Signed-off-by: Alan Stern
> Suggested-by: Akira Yokosawa
> Suggested-by: Andrea Parri
> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference")
>
The change itself looks good to me.
Acked-by: Akira Yokosawa
Thanks, Akira
> ---
>
> tools/memory-model/Documentation/cheatsheet.txt |6 +++---
> tools/memory-model/Documentation/explanation.txt |4 ++--
> tools/memory-model/linux-kernel.def |2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> Index: usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
> ===
> --- usb-4.x.orig/tools/memory-model/Documentation/cheatsheet.txt
> +++ usb-4.x/tools/memory-model/Documentation/cheatsheet.txt
> @@ -1,11 +1,11 @@
>Prior Operation Subsequent Operation
>---
> ---
> C Self R W RWM Self R W DR DW RMW
> SV
> - __ - - --- - - -- -- ---
> --
> + -- - - --- - - -- -- ---
> --
>
> Store, e.g., WRITE_ONCE()Y
> Y
> -Load, e.g., READ_ONCE() Y Y
> Y
> -Unsuccessful RMW operation Y Y
> Y
> +Load, e.g., READ_ONCE() Y Y Y
> Y
> +Unsuccessful RMW operation Y Y Y
> Y
> rcu_dereference()Y Y Y
> Y
> Successful *_acquire() R Y Y Y YY
> Y
> Successful *_release() CY YY W
> Y
> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt
> ===
> --- usb-4.x.orig/tools/memory-model/Documentation/explanation.txt
> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt
> @@ -826,7 +826,7 @@ A-cumulative; they only affect the propa
> executed on C before the fence (i.e., those which precede the fence in
> program order).
>
> -read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
> +read_read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
> other properties which we discuss later.
>
>
> @@ -1138,7 +1138,7 @@ final effect is that even though the two
> program order, it appears that they aren't.
>
> This could not have happened if the local cache had processed the
> -incoming stores in FIFO order. In constrast, other architectures
> +incoming stores in FIFO order. By contrast, other architectures
> maintain at least the appearance of FIFO order.
>
> In practice, this difficulty is solved by inserting a special fence
> Index: usb-4.x/tools/memory-model/linux-kernel.def
> ===
> --- usb-4.x.orig/tools/memory-model/linux-kernel.def
> +++ usb-4.x/tools/memory-model/linux-kernel.def
> @@ -13,7 +13,7 @@ WRITE_ONCE(X,V) { __store{once}(X,V); }
> smp_store_release(X,V) { __store{release}(*X,V); }
> smp_load_acquire(X) __load{acquire}(*X)
> rcu_assign_pointer(X,V) { __store{release}(X,V); }
> -rcu_dereference(X) __load{deref}(X)
> +rcu_dereference(X) __load{once}(X)
>
> // Fences
> smp_mb() { __fence{mb} ; }
>
Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
On 2018/02/14 14:52:38 -0800, Paul E. McKenney wrote:
> On Thu, Feb 15, 2018 at 07:20:35AM +0900, Akira Yokosawa wrote:
>> On 2018/02/09 17:07:03 -0800, Paul E. McKenney wrote:
>>> On Sat, Feb 10, 2018 at 08:46:25AM +0900, Akira Yokosawa wrote:
>>>> >From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
>>>> From: Akira Yokosawa <aki...@gmail.com>
>>>> Date: Fri, 9 Feb 2018 04:51:05 -0800
>>>> Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-"
>>>> -> "_")
>>>>
>>>> As of herd7 7.47, these '-'s are not permitted and end up in
>>>> errors such as:
>>>>
>>>> File "./linux-kernel.def", line 44, characters 29-30:
>>>> unexpected '-' (in macros)
>>>>
>>>> Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
>>>> identifiers match ASPLOS paper") in the repository at
>>>> https://github.com/aparri/memory-model can restore the compatibility
>>>> with herd7 7.47.
>>>>
>>>> Reported-by: Patrick Bellasi <patrick.bell...@arm.com>
>>>> Suggested-by: Andrea Parri <parri.and...@gmail.com>
>>>> Signed-off-by: Akira Yokosawa <aki...@gmail.com>
>>>> ---
>>>> Paul,
>>>>
>>>> FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
>>>
>>> Thank you, Akira!
>>>
>>> I am going to hold off on this for a bit to see if we can instead get
>>> a new release of herd7, but if we can't. this might well be a very good
>>> way to go.
>>
>> So, herdtools7.7.48 is now available by "opam update; opam upgrade".
>> Maybe mentioning the required version of herdtools7 in README would help.
>
> Or have some way for the memory model's .cat files to state what version
> they need, but in the meantime please see the patch below. But even with
> such version specification, we probably want to have the version in the
> README...
>
>> One glitch I'm aware of is one of the output of klitmus7 fails to
>> compile on kernels prior to 4.14, because of smp_mb__after_spinlock()
>> used in Z6.0+pooncelock+poonceLock+pombonce.litmus.
>
> This is one advantage of having the memory model in the kernel source
> itself -- the versions match. And people can always fire up a different
> kernel version (for example, within a VM) to run the output of klitmus7.
>
There is another unfortunate mismatch in kernel and herdtools7 updates.
klitmus7 in herdtools7 7.48 requires definition of ACCESS_ONCE() in kernel
headers, but it has been removed in Linux 4.15. This means klitmus7 of
herdtools7 7.48 works only on Linux 4.14.
In the repository of herdtools7, with the suggestion of Andrea, commit
e87d7f9287d1 ("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated
ACCESS_ONCE in "user" synchronization barrier") has addressed the issue.
This series is intended to be merged in Linux 4.17 merge window,
and hopefully we can have another update of herdtools7 by the time the merge
window opens...
Dependency to out-of-tree tools looks quite tricky. We need some neat way to
manage things.
Umm...
Thanks, Akira
[...]
Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
On 2018/02/14 14:52:38 -0800, Paul E. McKenney wrote:
> On Thu, Feb 15, 2018 at 07:20:35AM +0900, Akira Yokosawa wrote:
>> On 2018/02/09 17:07:03 -0800, Paul E. McKenney wrote:
>>> On Sat, Feb 10, 2018 at 08:46:25AM +0900, Akira Yokosawa wrote:
>>>> >From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
>>>> From: Akira Yokosawa
>>>> Date: Fri, 9 Feb 2018 04:51:05 -0800
>>>> Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-"
>>>> -> "_")
>>>>
>>>> As of herd7 7.47, these '-'s are not permitted and end up in
>>>> errors such as:
>>>>
>>>> File "./linux-kernel.def", line 44, characters 29-30:
>>>> unexpected '-' (in macros)
>>>>
>>>> Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
>>>> identifiers match ASPLOS paper") in the repository at
>>>> https://github.com/aparri/memory-model can restore the compatibility
>>>> with herd7 7.47.
>>>>
>>>> Reported-by: Patrick Bellasi
>>>> Suggested-by: Andrea Parri
>>>> Signed-off-by: Akira Yokosawa
>>>> ---
>>>> Paul,
>>>>
>>>> FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
>>>
>>> Thank you, Akira!
>>>
>>> I am going to hold off on this for a bit to see if we can instead get
>>> a new release of herd7, but if we can't. this might well be a very good
>>> way to go.
>>
>> So, herdtools7.7.48 is now available by "opam update; opam upgrade".
>> Maybe mentioning the required version of herdtools7 in README would help.
>
> Or have some way for the memory model's .cat files to state what version
> they need, but in the meantime please see the patch below. But even with
> such version specification, we probably want to have the version in the
> README...
>
>> One glitch I'm aware of is one of the output of klitmus7 fails to
>> compile on kernels prior to 4.14, because of smp_mb__after_spinlock()
>> used in Z6.0+pooncelock+poonceLock+pombonce.litmus.
>
> This is one advantage of having the memory model in the kernel source
> itself -- the versions match. And people can always fire up a different
> kernel version (for example, within a VM) to run the output of klitmus7.
>
There is another unfortunate mismatch in kernel and herdtools7 updates.
klitmus7 in herdtools7 7.48 requires definition of ACCESS_ONCE() in kernel
headers, but it has been removed in Linux 4.15. This means klitmus7 of
herdtools7 7.48 works only on Linux 4.14.
In the repository of herdtools7, with the suggestion of Andrea, commit
e87d7f9287d1 ("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated
ACCESS_ONCE in "user" synchronization barrier") has addressed the issue.
This series is intended to be merged in Linux 4.17 merge window,
and hopefully we can have another update of herdtools7 by the time the merge
window opens...
Dependency to out-of-tree tools looks quite tricky. We need some neat way to
manage things.
Umm...
Thanks, Akira
[...]
Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/16 17:22:55 -0500, Alan Stern wrote:
> Since commit 76ebbe78f739 ("locking/barriers: Add implicit
> smp_read_barrier_depends() to READ_ONCE()") was merged for the 4.15
> kernel, it has not been necessary to use smp_read_barrier_depends().
> Similarly, commit 59ecbbe7b31c ("locking/barriers: Kill
> lockless_dereference()") removed lockless_dereference() from the
> kernel.
>
> Since these primitives are no longer part of the kernel, they do not
> belong in the Linux Kernel Memory Consistency Model. This patch
> removes them, along with the internal rb-dep relation, and updates the
> revelant documentation.
>
> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
>
A few nits. Please see inline comments below.
With those fixed,
Reviewed-by: Akira Yokosawa <aki...@gmail.com>
Thanks, Akira
> ---
>
> Index: usb-4.x/tools/memory-model/linux-kernel.cat
> ===
> --- usb-4.x/tools/memory-model.orig/linux-kernel.cat
> +++ usb-4.x/tools/memory-model/linux-kernel.cat
> @@ -25,7 +25,6 @@ include "lock.cat"
> (***)
>
> (* Fences *)
> -let rb-dep = [R] ; fencerel(Rb_dep) ; [R]
> let rmb = [R \ Noreturn] ; fencerel(Rmb) ; [R \ Noreturn]
> let wmb = [W] ; fencerel(Wmb) ; [W]
> let mb = ([M] ; fencerel(Mb) ; [M]) |
> @@ -61,11 +60,9 @@ let dep = addr | data
> let rwdep = (dep | ctrl) ; [W]
> let overwrite = co | fr
> let to-w = rwdep | (overwrite & int)
> -let rrdep = addr | (dep ; rfi)
> -let strong-rrdep = rrdep+ & rb-dep
> -let to-r = strong-rrdep | rfi-rel-acq
> +let to-r = addr | (dep ; rfi) | rfi-rel-acq
> let fence = strong-fence | wmb | po-rel | rmb | acq-po
> -let ppo = rrdep* ; (to-r | to-w | fence)
> +let ppo = to-r | to-w | fence
>
> (* Propagation: Ordering from release operations and strong fences. *)
> let A-cumul(r) = rfe? ; r
> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt
> ===
> --- usb-4.x/tools/memory-model.orig/Documentation/explanation.txt
> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt
> @@ -1,5 +1,5 @@
> -Explanation of the Linux-Kernel Memory Model
> -
> +Explanation of the Linux-Kernel Memory Consistency Model
> +
>
> :Author: Alan Stern <st...@rowland.harvard.edu>
> :Created: October 2017
> @@ -35,25 +35,24 @@ Explanation of the Linux-Kernel Memory M
> INTRODUCTION
>
>
> -The Linux-kernel memory model (LKMM) is rather complex and obscure.
> -This is particularly evident if you read through the linux-kernel.bell
> -and linux-kernel.cat files that make up the formal version of the
> -memory model; they are extremely terse and their meanings are far from
> -clear.
> +The Linux-kernel memory consistency model (LKMM) is rather complex and
> +obscure. This is particularly evident if you read through the
> +linux-kernel.bell and linux-kernel.cat files that make up the formal
> +version of the model; they are extremely terse and their meanings are
> +far from clear.
>
> This document describes the ideas underlying the LKMM. It is meant
> -for people who want to understand how the memory model was designed.
> -It does not go into the details of the code in the .bell and .cat
> -files; rather, it explains in English what the code expresses
> -symbolically.
> +for people who want to understand how the model was designed. It does
> +not go into the details of the code in the .bell and .cat files;
> +rather, it explains in English what the code expresses symbolically.
>
> Sections 2 (BACKGROUND) through 5 (ORDERING AND CYCLES) are aimed
> -toward beginners; they explain what memory models are and the basic
> -notions shared by all such models. People already familiar with these
> -concepts can skim or skip over them. Sections 6 (EVENTS) through 12
> -(THE FROM_READS RELATION) describe the fundamental relations used in
> -many memory models. Starting in Section 13 (AN OPERATIONAL MODEL),
> -the workings of the LKMM itself are covered.
> +toward beginners; they explain what memory consistency models are and
> +the basic notions shared by all such models. People already familiar
> +with these concepts can skim or skip over them. Sections 6 (EVENTS)
> +through 12 (THE FROM_READS RELATION) describe the fundamental
> +relations used in many models. Starting in Section 13 (AN OPERATIONAL
> +MODEL), the workings of the LKMM itself are covered.
>
> Warning: The code examples in this document are not written in the
> proper format
Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference
On 2018/02/16 17:22:55 -0500, Alan Stern wrote:
> Since commit 76ebbe78f739 ("locking/barriers: Add implicit
> smp_read_barrier_depends() to READ_ONCE()") was merged for the 4.15
> kernel, it has not been necessary to use smp_read_barrier_depends().
> Similarly, commit 59ecbbe7b31c ("locking/barriers: Kill
> lockless_dereference()") removed lockless_dereference() from the
> kernel.
>
> Since these primitives are no longer part of the kernel, they do not
> belong in the Linux Kernel Memory Consistency Model. This patch
> removes them, along with the internal rb-dep relation, and updates the
> revelant documentation.
>
> Signed-off-by: Alan Stern
>
A few nits. Please see inline comments below.
With those fixed,
Reviewed-by: Akira Yokosawa
Thanks, Akira
> ---
>
> Index: usb-4.x/tools/memory-model/linux-kernel.cat
> ===
> --- usb-4.x/tools/memory-model.orig/linux-kernel.cat
> +++ usb-4.x/tools/memory-model/linux-kernel.cat
> @@ -25,7 +25,6 @@ include "lock.cat"
> (***)
>
> (* Fences *)
> -let rb-dep = [R] ; fencerel(Rb_dep) ; [R]
> let rmb = [R \ Noreturn] ; fencerel(Rmb) ; [R \ Noreturn]
> let wmb = [W] ; fencerel(Wmb) ; [W]
> let mb = ([M] ; fencerel(Mb) ; [M]) |
> @@ -61,11 +60,9 @@ let dep = addr | data
> let rwdep = (dep | ctrl) ; [W]
> let overwrite = co | fr
> let to-w = rwdep | (overwrite & int)
> -let rrdep = addr | (dep ; rfi)
> -let strong-rrdep = rrdep+ & rb-dep
> -let to-r = strong-rrdep | rfi-rel-acq
> +let to-r = addr | (dep ; rfi) | rfi-rel-acq
> let fence = strong-fence | wmb | po-rel | rmb | acq-po
> -let ppo = rrdep* ; (to-r | to-w | fence)
> +let ppo = to-r | to-w | fence
>
> (* Propagation: Ordering from release operations and strong fences. *)
> let A-cumul(r) = rfe? ; r
> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt
> ===
> --- usb-4.x/tools/memory-model.orig/Documentation/explanation.txt
> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt
> @@ -1,5 +1,5 @@
> -Explanation of the Linux-Kernel Memory Model
> -
> +Explanation of the Linux-Kernel Memory Consistency Model
> +
>
> :Author: Alan Stern
> :Created: October 2017
> @@ -35,25 +35,24 @@ Explanation of the Linux-Kernel Memory M
> INTRODUCTION
>
>
> -The Linux-kernel memory model (LKMM) is rather complex and obscure.
> -This is particularly evident if you read through the linux-kernel.bell
> -and linux-kernel.cat files that make up the formal version of the
> -memory model; they are extremely terse and their meanings are far from
> -clear.
> +The Linux-kernel memory consistency model (LKMM) is rather complex and
> +obscure. This is particularly evident if you read through the
> +linux-kernel.bell and linux-kernel.cat files that make up the formal
> +version of the model; they are extremely terse and their meanings are
> +far from clear.
>
> This document describes the ideas underlying the LKMM. It is meant
> -for people who want to understand how the memory model was designed.
> -It does not go into the details of the code in the .bell and .cat
> -files; rather, it explains in English what the code expresses
> -symbolically.
> +for people who want to understand how the model was designed. It does
> +not go into the details of the code in the .bell and .cat files;
> +rather, it explains in English what the code expresses symbolically.
>
> Sections 2 (BACKGROUND) through 5 (ORDERING AND CYCLES) are aimed
> -toward beginners; they explain what memory models are and the basic
> -notions shared by all such models. People already familiar with these
> -concepts can skim or skip over them. Sections 6 (EVENTS) through 12
> -(THE FROM_READS RELATION) describe the fundamental relations used in
> -many memory models. Starting in Section 13 (AN OPERATIONAL MODEL),
> -the workings of the LKMM itself are covered.
> +toward beginners; they explain what memory consistency models are and
> +the basic notions shared by all such models. People already familiar
> +with these concepts can skim or skip over them. Sections 6 (EVENTS)
> +through 12 (THE FROM_READS RELATION) describe the fundamental
> +relations used in many models. Starting in Section 13 (AN OPERATIONAL
> +MODEL), the workings of the LKMM itself are covered.
>
> Warning: The code examples in this document are not written in the
> proper format for litmus tests. They don't include a header line, the
> @@ -827,8 +
Re: Trial of conflict resolution of Alan's patch
On 2018/02/15 11:29:14 -0800, Paul E. McKenney wrote:
> On Thu, Feb 15, 2018 at 12:51:56PM -0500, Alan Stern wrote:
>> On Fri, 16 Feb 2018, Akira Yokosawa wrote:
>>
>>> So, I attempted to rebase the patch to current (somewhat old) master of
>>> https://github.com/aparri/memory-model. Why? Because the lkmm branch
>>> in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
>>>
>>> However, after this change, Z6.0+pooncelock+pooncelock+pombonce still
>>> has the result "Sometimes". I must have done something wrong in the
>>> conflict resolution.
>>>
>>> Note: I have almost no idea what this patch is doing. I'm just hoping
>>> to give a starting point of a discussion.
>>
>> Yes, that litmus test gives "Sometimes" both with and without the
>> patch. But consider instead this slightly changed version of that
>> test, in which P2 reads Z instead of writing it:
>>
>> C Z6.0-variant
>>
>> {}
>>
>> P0(int *x, int *y, spinlock_t *mylock)
>> {
>> spin_lock(mylock);
>> WRITE_ONCE(*x, 1);
>> WRITE_ONCE(*y, 1);
>> spin_unlock(mylock);
>> }
>>
>> P1(int *y, int *z, spinlock_t *mylock)
>> {
>> int r0;
>>
>> spin_lock(mylock);
>> r0 = READ_ONCE(*y);
>> WRITE_ONCE(*z, 1);
>> spin_unlock(mylock);
>> }
>>
>> P2(int *x, int *z)
>> {
>> int r1;
>> int r2;
>>
>> r2 = READ_ONCE(*z);
>> smp_mb();
>> r1 = READ_ONCE(*x);
>> }
>>
>> exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
>>
>> Without the patch, this test gives "Sometimes"; with the patch it gives
>> "Never". That is what I thought Paul was talking about originally.
>>
>> Sorry if my misunderstanding caused too much confusion for other
>> people.
>
> Ah, I did indeed get confused. I have changed the "Result:" for
> Z6.0+pooncelock+pooncelock+pombonce.litmus back to "Never", as in
> the patch below (which I merged into the patch adding all the
> comments).
>
> I have added the above test as ISA2+pooncelock+pooncelock+pombonce.litmus,
> with the Result: of Sometimes with you (Alan) as author and with your
> Signed-off-by -- please let me know if you would prefer some other
> approach.
>
> Please change the Result: when sending the proposed patch. Or please let
> me know if you would like me to apply the forward-port that Akira sent,
> in which case I will add the Result: change to that patch. Or for that
> matter, Akira might repost his forward-port of your patch with this change.
>
Hi,
My forward-port patch doesn't apply to the "lkmm" branch.
It looks like "linux-kernel-hardware.cat" is intentionally omitted there.
Am I guessing right?
If this is the case, I can prepare a patch to be applied to "lkmm".
But I can't compose a proper change log. So I'd like Alan to post
a patch with my SOB appended. Does this approach sound reasonable?
Thanks, Akira
> Thanx, Paul
>
>
>
> commit b2950420e1154131c0667f1ac58666bad3a06a69
> Author: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> Date: Thu Feb 15 10:35:25 2018 -0800
>
> fixup! EXP litmus_tests: Add comments explaining tests' purposes
>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
>
> diff --git
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> index fad47258a3e3..95890669859b 100644
> ---
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> +++
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> @@ -1,7 +1,7 @@
> C Z6.0+pooncelock+pooncelock+pombonce
>
> (*
> - * Result: Never
> + * Result: Somtimes
> *
> * This example demonstrates that a pair of accesses made by different
> * processes each while holding a given lock will not necessarily be
>
Re: Trial of conflict resolution of Alan's patch
On 2018/02/15 11:29:14 -0800, Paul E. McKenney wrote:
> On Thu, Feb 15, 2018 at 12:51:56PM -0500, Alan Stern wrote:
>> On Fri, 16 Feb 2018, Akira Yokosawa wrote:
>>
>>> So, I attempted to rebase the patch to current (somewhat old) master of
>>> https://github.com/aparri/memory-model. Why? Because the lkmm branch
>>> in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
>>>
>>> However, after this change, Z6.0+pooncelock+pooncelock+pombonce still
>>> has the result "Sometimes". I must have done something wrong in the
>>> conflict resolution.
>>>
>>> Note: I have almost no idea what this patch is doing. I'm just hoping
>>> to give a starting point of a discussion.
>>
>> Yes, that litmus test gives "Sometimes" both with and without the
>> patch. But consider instead this slightly changed version of that
>> test, in which P2 reads Z instead of writing it:
>>
>> C Z6.0-variant
>>
>> {}
>>
>> P0(int *x, int *y, spinlock_t *mylock)
>> {
>> spin_lock(mylock);
>> WRITE_ONCE(*x, 1);
>> WRITE_ONCE(*y, 1);
>> spin_unlock(mylock);
>> }
>>
>> P1(int *y, int *z, spinlock_t *mylock)
>> {
>> int r0;
>>
>> spin_lock(mylock);
>> r0 = READ_ONCE(*y);
>> WRITE_ONCE(*z, 1);
>> spin_unlock(mylock);
>> }
>>
>> P2(int *x, int *z)
>> {
>> int r1;
>> int r2;
>>
>> r2 = READ_ONCE(*z);
>> smp_mb();
>> r1 = READ_ONCE(*x);
>> }
>>
>> exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
>>
>> Without the patch, this test gives "Sometimes"; with the patch it gives
>> "Never". That is what I thought Paul was talking about originally.
>>
>> Sorry if my misunderstanding caused too much confusion for other
>> people.
>
> Ah, I did indeed get confused. I have changed the "Result:" for
> Z6.0+pooncelock+pooncelock+pombonce.litmus back to "Never", as in
> the patch below (which I merged into the patch adding all the
> comments).
>
> I have added the above test as ISA2+pooncelock+pooncelock+pombonce.litmus,
> with the Result: of Sometimes with you (Alan) as author and with your
> Signed-off-by -- please let me know if you would prefer some other
> approach.
>
> Please change the Result: when sending the proposed patch. Or please let
> me know if you would like me to apply the forward-port that Akira sent,
> in which case I will add the Result: change to that patch. Or for that
> matter, Akira might repost his forward-port of your patch with this change.
>
Hi,
My forward-port patch doesn't apply to the "lkmm" branch.
It looks like "linux-kernel-hardware.cat" is intentionally omitted there.
Am I guessing right?
If this is the case, I can prepare a patch to be applied to "lkmm".
But I can't compose a proper change log. So I'd like Alan to post
a patch with my SOB appended. Does this approach sound reasonable?
Thanks, Akira
> Thanx, Paul
>
>
>
> commit b2950420e1154131c0667f1ac58666bad3a06a69
> Author: Paul E. McKenney
> Date: Thu Feb 15 10:35:25 2018 -0800
>
> fixup! EXP litmus_tests: Add comments explaining tests' purposes
>
> Signed-off-by: Paul E. McKenney
>
> diff --git
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> index fad47258a3e3..95890669859b 100644
> ---
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> +++
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> @@ -1,7 +1,7 @@
> C Z6.0+pooncelock+pooncelock+pombonce
>
> (*
> - * Result: Never
> + * Result: Somtimes
> *
> * This example demonstrates that a pair of accesses made by different
> * processes each while holding a given lock will not necessarily be
>
Trial of conflict resolution of Alan's patch
>From 81bd6374057f0d89894ead482b870e2f001d2998 Mon Sep 17 00:00:00 2001 From: Alan Stern <st...@rowland.harvard.edu> Date: Fri, 16 Feb 2018 00:29:56 +0900 Subject: [PATCH] [TENTATIVE] Trial conflict resolution of Alan's patch This is a trial of conflict resolution of the patch Alan provided. Alan's message and original patch: Here's the relevant patch. It may need some manual adjustment, because it was not made against the files currently in the repository. Alan diff --git a/linux-kernel-hardware.cat b/linux-kernel-hardware.cat Index: memory-model/linux-kernel-hardware.cat === --- memory-model.orig/linux-kernel-hardware.cat +++ memory-model/linux-kernel-hardware.cat @@ -31,7 +31,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -57,13 +57,13 @@ let to-w = rwdep | addrpo | (overwrite & let rdw = po-loc & (fre ; rfe) let detour = po-loc & (coe ; rfe) let rrdep = addr | (dep ; rfi) -let to-r = rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = to-r | to-w | fence | rdw | detour (* Happens Before *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po let rec prop = (overwrite & ext)? ; cumul-fence ; hb* and hb = ppo | rfe | ((hb* ; prop) & int) Index: memory-model/linux-kernel.cat === --- memory-model.orig/linux-kernel.cat +++ memory-model/linux-kernel.cat @@ -31,7 +31,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -54,13 +54,13 @@ let rwdep = (dep | ctrl) ; [W] let overwrite = co | fr let to-w = rwdep | (overwrite & int) let rrdep = addr | (dep ; rfi) -let to-r = rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = to-r | to-w | fence (* Propagation: Ordering from release operations and strong fences. *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po let prop = (overwrite & ext)? ; cumul-fence* ; rfe? (* Signed-off-by: Alan Stern <st...@rowland.harvard.edu> [akiyks: Rebased to current master] Signed-off-by: Akira Yokosawa <aki...@gmail.com> --- So, I attempted to rebase the patch to current (somewhat old) master of https://github.com/aparri/memory-model. Why? Because the lkmm branch in Paul's -rcu tree doesn't have linux-kernel-hardware.cat. However, after this change, Z6.0+pooncelock+pooncelock+pombonce still has the result "Sometimes". I must have done something wrong in the conflict resolution. Note: I have almost no idea what this patch is doing. I'm just hoping to give a starting point of a discussion. Thanks, Akira -- linux-kernel-hardware.cat | 9 - linux-kernel.cat | 9 - 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/linux-kernel-hardware.cat b/linux-kernel-hardware.cat index 7768bf7..6c35655 100644 --- a/linux-kernel-hardware.cat +++ b/linux-kernel-hardware.cat @@ -34,7 +34,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -60,14 +60,13 @@ let to-w = rwdep | addrpo | (overwrite & int) let rdw = po-loc & (fre ; rfe) let detour = po-loc & (coe ; rfe) let rrdep = addr | (dep ; rfi) | rdw -let strong-rrdep = rrdep+ & rb-dep -let to-r = strong-rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = (rrdep* ; (to-r | to-w | fence)) | rdw | detour (* Happens Before *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence
Trial of conflict resolution of Alan's patch
>From 81bd6374057f0d89894ead482b870e2f001d2998 Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Fri, 16 Feb 2018 00:29:56 +0900 Subject: [PATCH] [TENTATIVE] Trial conflict resolution of Alan's patch This is a trial of conflict resolution of the patch Alan provided. Alan's message and original patch: Here's the relevant patch. It may need some manual adjustment, because it was not made against the files currently in the repository. Alan diff --git a/linux-kernel-hardware.cat b/linux-kernel-hardware.cat Index: memory-model/linux-kernel-hardware.cat === --- memory-model.orig/linux-kernel-hardware.cat +++ memory-model/linux-kernel-hardware.cat @@ -31,7 +31,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -57,13 +57,13 @@ let to-w = rwdep | addrpo | (overwrite & let rdw = po-loc & (fre ; rfe) let detour = po-loc & (coe ; rfe) let rrdep = addr | (dep ; rfi) -let to-r = rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = to-r | to-w | fence | rdw | detour (* Happens Before *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po let rec prop = (overwrite & ext)? ; cumul-fence ; hb* and hb = ppo | rfe | ((hb* ; prop) & int) Index: memory-model/linux-kernel.cat === --- memory-model.orig/linux-kernel.cat +++ memory-model/linux-kernel.cat @@ -31,7 +31,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -54,13 +54,13 @@ let rwdep = (dep | ctrl) ; [W] let overwrite = co | fr let to-w = rwdep | (overwrite & int) let rrdep = addr | (dep ; rfi) -let to-r = rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = to-r | to-w | fence (* Propagation: Ordering from release operations and strong fences. *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po let prop = (overwrite & ext)? ; cumul-fence* ; rfe? (* Signed-off-by: Alan Stern [akiyks: Rebased to current master] Signed-off-by: Akira Yokosawa --- So, I attempted to rebase the patch to current (somewhat old) master of https://github.com/aparri/memory-model. Why? Because the lkmm branch in Paul's -rcu tree doesn't have linux-kernel-hardware.cat. However, after this change, Z6.0+pooncelock+pooncelock+pombonce still has the result "Sometimes". I must have done something wrong in the conflict resolution. Note: I have almost no idea what this patch is doing. I'm just hoping to give a starting point of a discussion. Thanks, Akira -- linux-kernel-hardware.cat | 9 - linux-kernel.cat | 9 - 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/linux-kernel-hardware.cat b/linux-kernel-hardware.cat index 7768bf7..6c35655 100644 --- a/linux-kernel-hardware.cat +++ b/linux-kernel-hardware.cat @@ -34,7 +34,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -60,14 +60,13 @@ let to-w = rwdep | addrpo | (overwrite & int) let rdw = po-loc & (fre ; rfe) let detour = po-loc & (coe ; rfe) let rrdep = addr | (dep ; rfi) | rdw -let strong-rrdep = rrdep+ & rb-dep -let to-r = strong-rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = (rrdep* ; (to-r | to-w | fence)) | rdw | detour (* Happens Before *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po
Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
On 2018/02/09 17:07:03 -0800, Paul E. McKenney wrote:
> On Sat, Feb 10, 2018 at 08:46:25AM +0900, Akira Yokosawa wrote:
>> >From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa <aki...@gmail.com>
>> Date: Fri, 9 Feb 2018 04:51:05 -0800
>> Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" ->
>> "_")
>>
>> As of herd7 7.47, these '-'s are not permitted and end up in
>> errors such as:
>>
>> File "./linux-kernel.def", line 44, characters 29-30:
>> unexpected '-' (in macros)
>>
>> Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
>> identifiers match ASPLOS paper") in the repository at
>> https://github.com/aparri/memory-model can restore the compatibility
>> with herd7 7.47.
>>
>> Reported-by: Patrick Bellasi <patrick.bell...@arm.com>
>> Suggested-by: Andrea Parri <parri.and...@gmail.com>
>> Signed-off-by: Akira Yokosawa <aki...@gmail.com>
>> ---
>> Paul,
>>
>> FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
>
> Thank you, Akira!
>
> I am going to hold off on this for a bit to see if we can instead get
> a new release of herd7, but if we can't. this might well be a very good
> way to go.
So, herdtools7.7.48 is now available by "opam update; opam upgrade".
Maybe mentioning the required version of herdtools7 in README would help.
One glitch I'm aware of is one of the output of klitmus7 fails to
compile on kernels prior to 4.14, because of smp_mb__after_spinlock()
used in Z6.0+pooncelock+poonceLock+pombonce.litmus.
And there is a question I want to ask.
Z6.0+pooncelock+pooncelock+pombonce.litmus, which doesn't have
smp_mb__after_spinlock(), has a comment of:
(*
* Result: Never
*
* This example demonstrates that a pair of accesses made by different
* processes each while holding a given lock will not necessarily be
* seen as ordered by a third process not holding that lock.
*)
The result was changed from "Sometimes" to "Never" in response to
Alan's feedback the other day, but the following comment indicates
the result should be "Sometimes". And the current model gives the
result of "Sometimes".
As I have no idea of the pending patches, I'd like to know once
the pending patches are applied, would
Z6.0+pooncelock+pooncelock+pombonce.litmus and
Z6.0+pooncelock+poonceLock+pombonce.litmus become identical?
Thanks, Akira
>
> Thanx, Paul
[...]
d_lock*) ||
>> +'rcu_unlock (*rcu_read_unlock*) ||
>> +'sync_rcu (*synchronize_rcu*) ||
>> 'before_atomic (*smp_mb__before_atomic*) ||
>> 'after_atomic (*smp_mb__after_atomic*) ||
>> 'after_spinlock (*smp_mb__after_spinlock*)
>> @@ -35,8 +35,8 @@ instructions F[Barriers]
>>
>> (* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
>> let matched = let rec
>> -unmatched-locks = Rcu-lock \ domain(matched)
>> -and unmatched-unlocks = Rcu-unlock \ range(matched)
>> +unmatched-locks = Rcu_lock \ domain(matched)
>> +and unmatched-unlocks = Rcu_unlock \ range(matched)
>> and unmatched = unmatched-locks | unmatched-unlocks
>> and unmatched-po = [unmatched] ; po ; [unmatched]
>> and unmatched-locks-to-unlocks =
>> @@ -46,8 +46,8 @@ let matched = let rec
>> in matched
>>
>> (* Validate nesting *)
>> -flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
>> -flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
>>
>> (* Outermost level of nesting only *)
>> let crit = matched \ (po^-1 ; matched ; po^-1)
>> diff --git a/tools/memory-model/linux-kernel.cat
>> b/tools/memory-model/linux-kernel.cat
>> index babe2b3..d0085d5 100644
>> --- a/tools/memory-model/linux-kernel.cat
>> +++ b/tools/memory-model/linux-kernel.cat
>> @@ -32,7 +32,7 @@ let mb = ([M] ; fencerel(Mb) ; [M]) |
>> ([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
>> ([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
>> ([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
>> -let gp = po ; [Sync-rcu] ; po?
>> +let gp = po ; [Sync_rcu] ; po?
>>
>> let strong-fence = mb | gp
>>
>> diff --git a/tools/memory-model/linux-kernel.def
>> b/tools/memory-model/linux-kernel.def
>> index a397387..fc083
Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
On 2018/02/09 17:07:03 -0800, Paul E. McKenney wrote:
> On Sat, Feb 10, 2018 at 08:46:25AM +0900, Akira Yokosawa wrote:
>> >From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa
>> Date: Fri, 9 Feb 2018 04:51:05 -0800
>> Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" ->
>> "_")
>>
>> As of herd7 7.47, these '-'s are not permitted and end up in
>> errors such as:
>>
>> File "./linux-kernel.def", line 44, characters 29-30:
>> unexpected '-' (in macros)
>>
>> Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
>> identifiers match ASPLOS paper") in the repository at
>> https://github.com/aparri/memory-model can restore the compatibility
>> with herd7 7.47.
>>
>> Reported-by: Patrick Bellasi
>> Suggested-by: Andrea Parri
>> Signed-off-by: Akira Yokosawa
>> ---
>> Paul,
>>
>> FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
>
> Thank you, Akira!
>
> I am going to hold off on this for a bit to see if we can instead get
> a new release of herd7, but if we can't. this might well be a very good
> way to go.
So, herdtools7.7.48 is now available by "opam update; opam upgrade".
Maybe mentioning the required version of herdtools7 in README would help.
One glitch I'm aware of is one of the output of klitmus7 fails to
compile on kernels prior to 4.14, because of smp_mb__after_spinlock()
used in Z6.0+pooncelock+poonceLock+pombonce.litmus.
And there is a question I want to ask.
Z6.0+pooncelock+pooncelock+pombonce.litmus, which doesn't have
smp_mb__after_spinlock(), has a comment of:
(*
* Result: Never
*
* This example demonstrates that a pair of accesses made by different
* processes each while holding a given lock will not necessarily be
* seen as ordered by a third process not holding that lock.
*)
The result was changed from "Sometimes" to "Never" in response to
Alan's feedback the other day, but the following comment indicates
the result should be "Sometimes". And the current model gives the
result of "Sometimes".
As I have no idea of the pending patches, I'd like to know once
the pending patches are applied, would
Z6.0+pooncelock+pooncelock+pombonce.litmus and
Z6.0+pooncelock+poonceLock+pombonce.litmus become identical?
Thanks, Akira
>
> Thanx, Paul
[...]
d_lock*) ||
>> +'rcu_unlock (*rcu_read_unlock*) ||
>> +'sync_rcu (*synchronize_rcu*) ||
>> 'before_atomic (*smp_mb__before_atomic*) ||
>> 'after_atomic (*smp_mb__after_atomic*) ||
>> 'after_spinlock (*smp_mb__after_spinlock*)
>> @@ -35,8 +35,8 @@ instructions F[Barriers]
>>
>> (* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
>> let matched = let rec
>> -unmatched-locks = Rcu-lock \ domain(matched)
>> -and unmatched-unlocks = Rcu-unlock \ range(matched)
>> +unmatched-locks = Rcu_lock \ domain(matched)
>> +and unmatched-unlocks = Rcu_unlock \ range(matched)
>> and unmatched = unmatched-locks | unmatched-unlocks
>> and unmatched-po = [unmatched] ; po ; [unmatched]
>> and unmatched-locks-to-unlocks =
>> @@ -46,8 +46,8 @@ let matched = let rec
>> in matched
>>
>> (* Validate nesting *)
>> -flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
>> -flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
>>
>> (* Outermost level of nesting only *)
>> let crit = matched \ (po^-1 ; matched ; po^-1)
>> diff --git a/tools/memory-model/linux-kernel.cat
>> b/tools/memory-model/linux-kernel.cat
>> index babe2b3..d0085d5 100644
>> --- a/tools/memory-model/linux-kernel.cat
>> +++ b/tools/memory-model/linux-kernel.cat
>> @@ -32,7 +32,7 @@ let mb = ([M] ; fencerel(Mb) ; [M]) |
>> ([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
>> ([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
>> ([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
>> -let gp = po ; [Sync-rcu] ; po?
>> +let gp = po ; [Sync_rcu] ; po?
>>
>> let strong-fence = mb | gp
>>
>> diff --git a/tools/memory-model/linux-kernel.def
>> b/tools/memory-model/linux-kernel.def
>> index a397387..fc08371 100644
>> --- a/tools/memory-model/linux-kernel.def
>> +++ b/tools/memory-model/lin
Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
On 2018/02/10 10:07, Paul E. McKenney wrote:
> On Sat, Feb 10, 2018 at 08:46:25AM +0900, Akira Yokosawa wrote:
>> >From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa <aki...@gmail.com>
>> Date: Fri, 9 Feb 2018 04:51:05 -0800
>> Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" ->
>> "_")
>>
>> As of herd7 7.47, these '-'s are not permitted and end up in
>> errors such as:
>>
>> File "./linux-kernel.def", line 44, characters 29-30:
>> unexpected '-' (in macros)
>>
>> Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
>> identifiers match ASPLOS paper") in the repository at
>> https://github.com/aparri/memory-model can restore the compatibility
>> with herd7 7.47.
>>
>> Reported-by: Patrick Bellasi <patrick.bell...@arm.com>
>> Suggested-by: Andrea Parri <parri.and...@gmail.com>
>> Signed-off-by: Akira Yokosawa <aki...@gmail.com>
>> ---
>> Paul,
>>
>> FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
>
> Thank you, Akira!
>
> I am going to hold off on this for a bit to see if we can instead get
> a new release of herd7, but if we can't. this might well be a very good
> way to go.
Fair enough.
Thanks, Akira
>
> Thanx, Paul
>
>> Thanks, Akira
>> --
>> tools/memory-model/linux-kernel.bell | 14 +++---
>> tools/memory-model/linux-kernel.cat | 2 +-
>> tools/memory-model/linux-kernel.def | 8
>> 3 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/tools/memory-model/linux-kernel.bell
>> b/tools/memory-model/linux-kernel.bell
>> index b984bbd..436791b 100644
>> --- a/tools/memory-model/linux-kernel.bell
>> +++ b/tools/memory-model/linux-kernel.bell
>> @@ -25,9 +25,9 @@ enum Barriers = 'wmb (*smp_wmb*) ||
>> 'rmb (*smp_rmb*) ||
>> 'mb (*smp_mb*) ||
>> 'rb_dep (*smp_read_barrier_depends*) ||
>> -'rcu-lock (*rcu_read_lock*) ||
>> -'rcu-unlock (*rcu_read_unlock*) ||
>> -'sync-rcu (*synchronize_rcu*) ||
>> +'rcu_lock (*rcu_read_lock*) ||
>> +'rcu_unlock (*rcu_read_unlock*) ||
>> +'sync_rcu (*synchronize_rcu*) ||
>> 'before_atomic (*smp_mb__before_atomic*) ||
>> 'after_atomic (*smp_mb__after_atomic*) ||
>> 'after_spinlock (*smp_mb__after_spinlock*)
>> @@ -35,8 +35,8 @@ instructions F[Barriers]
>>
>> (* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
>> let matched = let rec
>> -unmatched-locks = Rcu-lock \ domain(matched)
>> -and unmatched-unlocks = Rcu-unlock \ range(matched)
>> +unmatched-locks = Rcu_lock \ domain(matched)
>> +and unmatched-unlocks = Rcu_unlock \ range(matched)
>> and unmatched = unmatched-locks | unmatched-unlocks
>> and unmatched-po = [unmatched] ; po ; [unmatched]
>> and unmatched-locks-to-unlocks =
>> @@ -46,8 +46,8 @@ let matched = let rec
>> in matched
>>
>> (* Validate nesting *)
>> -flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
>> -flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
>>
>> (* Outermost level of nesting only *)
>> let crit = matched \ (po^-1 ; matched ; po^-1)
>> diff --git a/tools/memory-model/linux-kernel.cat
>> b/tools/memory-model/linux-kernel.cat
>> index babe2b3..d0085d5 100644
>> --- a/tools/memory-model/linux-kernel.cat
>> +++ b/tools/memory-model/linux-kernel.cat
>> @@ -32,7 +32,7 @@ let mb = ([M] ; fencerel(Mb) ; [M]) |
>> ([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
>> ([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
>> ([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
>> -let gp = po ; [Sync-rcu] ; po?
>> +let gp = po ; [Sync_rcu] ; po?
>>
>> let strong-fence = mb | gp
>>
>> diff --git a/tools/memory-model/linux-kernel.def
>> b/tools/memory-model/linux-kernel.def
>> index a397387..fc08371 100644
>> --- a/tools/memory-model/linux-kernel.def
>> +++ b/tools/memory-model/linux-kernel.def
>> @@ -41,10 +41,10 @@ spin_unlock(X) { __unlock(X) ; }
>> spin_trylock(X) __trylock(X)
>>
>> // RCU
>> -rcu_read_lock() { __fence{rcu-lock}; }
>> -rcu_read_unlock() { __fence{rcu-unlock};}
>> -synchronize_rcu() { __fence{sync-rcu}; }
>> -synchronize_rcu_expedited() { __fence{sync-rcu}; }
>> +rcu_read_lock() { __fence{rcu_lock}; }
>> +rcu_read_unlock() { __fence{rcu_unlock};}
>> +synchronize_rcu() { __fence{sync_rcu}; }
>> +synchronize_rcu_expedited() { __fence{sync_rcu}; }
>>
>> // Atomic
>> atomic_read(X) READ_ONCE(*X)
>> --
>> 2.7.4
>>
>>
>
Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
On 2018/02/10 10:07, Paul E. McKenney wrote:
> On Sat, Feb 10, 2018 at 08:46:25AM +0900, Akira Yokosawa wrote:
>> >From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa
>> Date: Fri, 9 Feb 2018 04:51:05 -0800
>> Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" ->
>> "_")
>>
>> As of herd7 7.47, these '-'s are not permitted and end up in
>> errors such as:
>>
>> File "./linux-kernel.def", line 44, characters 29-30:
>> unexpected '-' (in macros)
>>
>> Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
>> identifiers match ASPLOS paper") in the repository at
>> https://github.com/aparri/memory-model can restore the compatibility
>> with herd7 7.47.
>>
>> Reported-by: Patrick Bellasi
>> Suggested-by: Andrea Parri
>> Signed-off-by: Akira Yokosawa
>> ---
>> Paul,
>>
>> FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
>
> Thank you, Akira!
>
> I am going to hold off on this for a bit to see if we can instead get
> a new release of herd7, but if we can't. this might well be a very good
> way to go.
Fair enough.
Thanks, Akira
>
> Thanx, Paul
>
>> Thanks, Akira
>> --
>> tools/memory-model/linux-kernel.bell | 14 +++---
>> tools/memory-model/linux-kernel.cat | 2 +-
>> tools/memory-model/linux-kernel.def | 8
>> 3 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/tools/memory-model/linux-kernel.bell
>> b/tools/memory-model/linux-kernel.bell
>> index b984bbd..436791b 100644
>> --- a/tools/memory-model/linux-kernel.bell
>> +++ b/tools/memory-model/linux-kernel.bell
>> @@ -25,9 +25,9 @@ enum Barriers = 'wmb (*smp_wmb*) ||
>> 'rmb (*smp_rmb*) ||
>> 'mb (*smp_mb*) ||
>> 'rb_dep (*smp_read_barrier_depends*) ||
>> -'rcu-lock (*rcu_read_lock*) ||
>> -'rcu-unlock (*rcu_read_unlock*) ||
>> -'sync-rcu (*synchronize_rcu*) ||
>> +'rcu_lock (*rcu_read_lock*) ||
>> +'rcu_unlock (*rcu_read_unlock*) ||
>> +'sync_rcu (*synchronize_rcu*) ||
>> 'before_atomic (*smp_mb__before_atomic*) ||
>> 'after_atomic (*smp_mb__after_atomic*) ||
>> 'after_spinlock (*smp_mb__after_spinlock*)
>> @@ -35,8 +35,8 @@ instructions F[Barriers]
>>
>> (* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
>> let matched = let rec
>> -unmatched-locks = Rcu-lock \ domain(matched)
>> -and unmatched-unlocks = Rcu-unlock \ range(matched)
>> +unmatched-locks = Rcu_lock \ domain(matched)
>> +and unmatched-unlocks = Rcu_unlock \ range(matched)
>> and unmatched = unmatched-locks | unmatched-unlocks
>> and unmatched-po = [unmatched] ; po ; [unmatched]
>> and unmatched-locks-to-unlocks =
>> @@ -46,8 +46,8 @@ let matched = let rec
>> in matched
>>
>> (* Validate nesting *)
>> -flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
>> -flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
>> +flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
>>
>> (* Outermost level of nesting only *)
>> let crit = matched \ (po^-1 ; matched ; po^-1)
>> diff --git a/tools/memory-model/linux-kernel.cat
>> b/tools/memory-model/linux-kernel.cat
>> index babe2b3..d0085d5 100644
>> --- a/tools/memory-model/linux-kernel.cat
>> +++ b/tools/memory-model/linux-kernel.cat
>> @@ -32,7 +32,7 @@ let mb = ([M] ; fencerel(Mb) ; [M]) |
>> ([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
>> ([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
>> ([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
>> -let gp = po ; [Sync-rcu] ; po?
>> +let gp = po ; [Sync_rcu] ; po?
>>
>> let strong-fence = mb | gp
>>
>> diff --git a/tools/memory-model/linux-kernel.def
>> b/tools/memory-model/linux-kernel.def
>> index a397387..fc08371 100644
>> --- a/tools/memory-model/linux-kernel.def
>> +++ b/tools/memory-model/linux-kernel.def
>> @@ -41,10 +41,10 @@ spin_unlock(X) { __unlock(X) ; }
>> spin_trylock(X) __trylock(X)
>>
>> // RCU
>> -rcu_read_lock() { __fence{rcu-lock}; }
>> -rcu_read_unlock() { __fence{rcu-unlock};}
>> -synchronize_rcu() { __fence{sync-rcu}; }
>> -synchronize_rcu_expedited() { __fence{sync-rcu}; }
>> +rcu_read_lock() { __fence{rcu_lock}; }
>> +rcu_read_unlock() { __fence{rcu_unlock};}
>> +synchronize_rcu() { __fence{sync_rcu}; }
>> +synchronize_rcu_expedited() { __fence{sync_rcu}; }
>>
>> // Atomic
>> atomic_read(X) READ_ONCE(*X)
>> --
>> 2.7.4
>>
>>
>
[PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
>From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <aki...@gmail.com>
Date: Fri, 9 Feb 2018 04:51:05 -0800
Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
As of herd7 7.47, these '-'s are not permitted and end up in
errors such as:
File "./linux-kernel.def", line 44, characters 29-30:
unexpected '-' (in macros)
Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
identifiers match ASPLOS paper") in the repository at
https://github.com/aparri/memory-model can restore the compatibility
with herd7 7.47.
Reported-by: Patrick Bellasi <patrick.bell...@arm.com>
Suggested-by: Andrea Parri <parri.and...@gmail.com>
Signed-off-by: Akira Yokosawa <aki...@gmail.com>
---
Paul,
FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
Thanks, Akira
--
tools/memory-model/linux-kernel.bell | 14 +++---
tools/memory-model/linux-kernel.cat | 2 +-
tools/memory-model/linux-kernel.def | 8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/memory-model/linux-kernel.bell
b/tools/memory-model/linux-kernel.bell
index b984bbd..436791b 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -25,9 +25,9 @@ enum Barriers = 'wmb (*smp_wmb*) ||
'rmb (*smp_rmb*) ||
'mb (*smp_mb*) ||
'rb_dep (*smp_read_barrier_depends*) ||
- 'rcu-lock (*rcu_read_lock*) ||
- 'rcu-unlock (*rcu_read_unlock*) ||
- 'sync-rcu (*synchronize_rcu*) ||
+ 'rcu_lock (*rcu_read_lock*) ||
+ 'rcu_unlock (*rcu_read_unlock*) ||
+ 'sync_rcu (*synchronize_rcu*) ||
'before_atomic (*smp_mb__before_atomic*) ||
'after_atomic (*smp_mb__after_atomic*) ||
'after_spinlock (*smp_mb__after_spinlock*)
@@ -35,8 +35,8 @@ instructions F[Barriers]
(* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
let matched = let rec
- unmatched-locks = Rcu-lock \ domain(matched)
- and unmatched-unlocks = Rcu-unlock \ range(matched)
+ unmatched-locks = Rcu_lock \ domain(matched)
+ and unmatched-unlocks = Rcu_unlock \ range(matched)
and unmatched = unmatched-locks | unmatched-unlocks
and unmatched-po = [unmatched] ; po ; [unmatched]
and unmatched-locks-to-unlocks =
@@ -46,8 +46,8 @@ let matched = let rec
in matched
(* Validate nesting *)
-flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
-flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
(* Outermost level of nesting only *)
let crit = matched \ (po^-1 ; matched ; po^-1)
diff --git a/tools/memory-model/linux-kernel.cat
b/tools/memory-model/linux-kernel.cat
index babe2b3..d0085d5 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -32,7 +32,7 @@ let mb = ([M] ; fencerel(Mb) ; [M]) |
([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
-let gp = po ; [Sync-rcu] ; po?
+let gp = po ; [Sync_rcu] ; po?
let strong-fence = mb | gp
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index a397387..fc08371 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -41,10 +41,10 @@ spin_unlock(X) { __unlock(X) ; }
spin_trylock(X) __trylock(X)
// RCU
-rcu_read_lock() { __fence{rcu-lock}; }
-rcu_read_unlock() { __fence{rcu-unlock};}
-synchronize_rcu() { __fence{sync-rcu}; }
-synchronize_rcu_expedited() { __fence{sync-rcu}; }
+rcu_read_lock() { __fence{rcu_lock}; }
+rcu_read_unlock() { __fence{rcu_unlock};}
+synchronize_rcu() { __fence{sync_rcu}; }
+synchronize_rcu_expedited() { __fence{sync_rcu}; }
// Atomic
atomic_read(X) READ_ONCE(*X)
--
2.7.4
[PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
>From 7c1f497a9a51e8db1a94c8a7ef0b74b235aaab88 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Fri, 9 Feb 2018 04:51:05 -0800
Subject: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")
As of herd7 7.47, these '-'s are not permitted and end up in
errors such as:
File "./linux-kernel.def", line 44, characters 29-30:
unexpected '-' (in macros)
Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
identifiers match ASPLOS paper") in the repository at
https://github.com/aparri/memory-model can restore the compatibility
with herd7 7.47.
Reported-by: Patrick Bellasi
Suggested-by: Andrea Parri
Signed-off-by: Akira Yokosawa
---
Paul,
FWIW, this is a squashed version relative to patch 07/10 in the RFC series.
Thanks, Akira
--
tools/memory-model/linux-kernel.bell | 14 +++---
tools/memory-model/linux-kernel.cat | 2 +-
tools/memory-model/linux-kernel.def | 8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/memory-model/linux-kernel.bell
b/tools/memory-model/linux-kernel.bell
index b984bbd..436791b 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -25,9 +25,9 @@ enum Barriers = 'wmb (*smp_wmb*) ||
'rmb (*smp_rmb*) ||
'mb (*smp_mb*) ||
'rb_dep (*smp_read_barrier_depends*) ||
- 'rcu-lock (*rcu_read_lock*) ||
- 'rcu-unlock (*rcu_read_unlock*) ||
- 'sync-rcu (*synchronize_rcu*) ||
+ 'rcu_lock (*rcu_read_lock*) ||
+ 'rcu_unlock (*rcu_read_unlock*) ||
+ 'sync_rcu (*synchronize_rcu*) ||
'before_atomic (*smp_mb__before_atomic*) ||
'after_atomic (*smp_mb__after_atomic*) ||
'after_spinlock (*smp_mb__after_spinlock*)
@@ -35,8 +35,8 @@ instructions F[Barriers]
(* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
let matched = let rec
- unmatched-locks = Rcu-lock \ domain(matched)
- and unmatched-unlocks = Rcu-unlock \ range(matched)
+ unmatched-locks = Rcu_lock \ domain(matched)
+ and unmatched-unlocks = Rcu_unlock \ range(matched)
and unmatched = unmatched-locks | unmatched-unlocks
and unmatched-po = [unmatched] ; po ; [unmatched]
and unmatched-locks-to-unlocks =
@@ -46,8 +46,8 @@ let matched = let rec
in matched
(* Validate nesting *)
-flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
-flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
(* Outermost level of nesting only *)
let crit = matched \ (po^-1 ; matched ; po^-1)
diff --git a/tools/memory-model/linux-kernel.cat
b/tools/memory-model/linux-kernel.cat
index babe2b3..d0085d5 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -32,7 +32,7 @@ let mb = ([M] ; fencerel(Mb) ; [M]) |
([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
-let gp = po ; [Sync-rcu] ; po?
+let gp = po ; [Sync_rcu] ; po?
let strong-fence = mb | gp
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index a397387..fc08371 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -41,10 +41,10 @@ spin_unlock(X) { __unlock(X) ; }
spin_trylock(X) __trylock(X)
// RCU
-rcu_read_lock() { __fence{rcu-lock}; }
-rcu_read_unlock() { __fence{rcu-unlock};}
-synchronize_rcu() { __fence{sync-rcu}; }
-synchronize_rcu_expedited() { __fence{sync-rcu}; }
+rcu_read_lock() { __fence{rcu_lock}; }
+rcu_read_unlock() { __fence{rcu_unlock};}
+synchronize_rcu() { __fence{sync_rcu}; }
+synchronize_rcu_expedited() { __fence{sync_rcu}; }
// Atomic
atomic_read(X) READ_ONCE(*X)
--
2.7.4
[PATCH] tools/memory-model: Restore compat with herd7 7.47 ("-" -> "_")
>From 9a0de4d75e18ef8e25a1096f88c7a970d9d693f5 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <aki...@gmail.com>
Date: Sat, 10 Feb 2018 00:45:25 +0900
Subject: [PATCH] tools/memory-model: Restore compat with herd7 7.47 ("-" -> "_")
As of herd7 7.47, these '-'s are not permitted and end up in
an error:
File "./linux-kernel.def", line 44, characters 29-30:
unexpected '-' (in macros)
Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
identifiers match ASPLOS paper") in the repository at
https://github.com/aparri/memory-model can restore the compatibility
with herd7 7.47.
Reported-by: Patrick Bellasi <patrick.bell...@arm.com>
Suggested-by: Andrea Parri <parri.and...@gmail.com>
Signed-off-by: Akira Yokosawa <aki...@gmail.com>
---
tools/memory-model/linux-kernel.bell | 20 ++--
tools/memory-model/linux-kernel.cat | 8
tools/memory-model/linux-kernel.def | 14 +++---
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/tools/memory-model/linux-kernel.bell
b/tools/memory-model/linux-kernel.bell
index 18885ad..436791b 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -25,18 +25,18 @@ enum Barriers = 'wmb (*smp_wmb*) ||
'rmb (*smp_rmb*) ||
'mb (*smp_mb*) ||
'rb_dep (*smp_read_barrier_depends*) ||
- 'rcu-lock (*rcu_read_lock*) ||
- 'rcu-unlock (*rcu_read_unlock*) ||
- 'sync-rcu (*synchronize_rcu*) ||
- 'before-atomic (*smp_mb__before_atomic*) ||
- 'after-atomic (*smp_mb__after_atomic*) ||
- 'after-spinlock (*smp_mb__after_spinlock*)
+ 'rcu_lock (*rcu_read_lock*) ||
+ 'rcu_unlock (*rcu_read_unlock*) ||
+ 'sync_rcu (*synchronize_rcu*) ||
+ 'before_atomic (*smp_mb__before_atomic*) ||
+ 'after_atomic (*smp_mb__after_atomic*) ||
+ 'after_spinlock (*smp_mb__after_spinlock*)
instructions F[Barriers]
(* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
let matched = let rec
- unmatched-locks = Rcu-lock \ domain(matched)
- and unmatched-unlocks = Rcu-unlock \ range(matched)
+ unmatched-locks = Rcu_lock \ domain(matched)
+ and unmatched-unlocks = Rcu_unlock \ range(matched)
and unmatched = unmatched-locks | unmatched-unlocks
and unmatched-po = [unmatched] ; po ; [unmatched]
and unmatched-locks-to-unlocks =
@@ -46,8 +46,8 @@ let matched = let rec
in matched
(* Validate nesting *)
-flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
-flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
(* Outermost level of nesting only *)
let crit = matched \ (po^-1 ; matched ; po^-1)
diff --git a/tools/memory-model/linux-kernel.cat
b/tools/memory-model/linux-kernel.cat
index f0d27f8..d0085d5 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -29,10 +29,10 @@ let rb-dep = [R] ; fencerel(Rb_dep) ; [R]
let rmb = [R \ Noreturn] ; fencerel(Rmb) ; [R \ Noreturn]
let wmb = [W] ; fencerel(Wmb) ; [W]
let mb = ([M] ; fencerel(Mb) ; [M]) |
- ([M] ; fencerel(Before-atomic) ; [RMW] ; po? ; [M]) |
- ([M] ; po? ; [RMW] ; fencerel(After-atomic) ; [M]) |
- ([M] ; po? ; [LKW] ; fencerel(After-spinlock) ; [M])
-let gp = po ; [Sync-rcu] ; po?
+ ([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
+ ([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
+ ([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
+let gp = po ; [Sync_rcu] ; po?
let strong-fence = mb | gp
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index f5a1eb0..fc08371 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -21,9 +21,9 @@ smp_mb() { __fence{mb} ; }
smp_rmb() { __fence{rmb} ; }
smp_wmb() { __fence{wmb} ; }
smp_read_barrier_depends() { __fence{rb_dep}; }
-smp_mb__before_atomic() { __fence{before-atomic} ; }
-smp_mb__after_atomic() { __fence{after-atomic} ; }
-smp_mb__after_spinlock() { __fence{after-spinlock} ; }
+smp_mb__before_atomic() { __fence{before_atomic} ; }
+smp_mb__after_atomic() { __fence{after_atomic} ; }
+smp_mb__after_spinlock() { __fence{after_spinlock} ; }
// Exchange
xchg(X,V) __xchg{mb}(X,V)
@@ -41,10 +41,10 @@ spin_unlock(X) { __unlock(X) ; }
spin_trylock(X) __trylock(X)
// RCU
-rcu_read_lock() { __fence{rcu-lock}; }
-rcu_read_unlock() { __fence{rcu-unlock};}
-synchronize_rcu() { __fence{sync-rcu}; }
-synchronize_rcu_expedited() { __fence{sync-rcu}; }
+rcu_read_lock() { __fence{rcu_lock}; }
+rcu_read_unlock() { __fence{rcu_unlock};}
+synchroni
[PATCH] tools/memory-model: Restore compat with herd7 7.47 ("-" -> "_")
>From 9a0de4d75e18ef8e25a1096f88c7a970d9d693f5 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sat, 10 Feb 2018 00:45:25 +0900
Subject: [PATCH] tools/memory-model: Restore compat with herd7 7.47 ("-" -> "_")
As of herd7 7.47, these '-'s are not permitted and end up in
an error:
File "./linux-kernel.def", line 44, characters 29-30:
unexpected '-' (in macros)
Partial revert of commit 2d5fba7782d6 ("linux-kernel*: Make RCU
identifiers match ASPLOS paper") in the repository at
https://github.com/aparri/memory-model can restore the compatibility
with herd7 7.47.
Reported-by: Patrick Bellasi
Suggested-by: Andrea Parri
Signed-off-by: Akira Yokosawa
---
tools/memory-model/linux-kernel.bell | 20 ++--
tools/memory-model/linux-kernel.cat | 8
tools/memory-model/linux-kernel.def | 14 +++---
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/tools/memory-model/linux-kernel.bell
b/tools/memory-model/linux-kernel.bell
index 18885ad..436791b 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -25,18 +25,18 @@ enum Barriers = 'wmb (*smp_wmb*) ||
'rmb (*smp_rmb*) ||
'mb (*smp_mb*) ||
'rb_dep (*smp_read_barrier_depends*) ||
- 'rcu-lock (*rcu_read_lock*) ||
- 'rcu-unlock (*rcu_read_unlock*) ||
- 'sync-rcu (*synchronize_rcu*) ||
- 'before-atomic (*smp_mb__before_atomic*) ||
- 'after-atomic (*smp_mb__after_atomic*) ||
- 'after-spinlock (*smp_mb__after_spinlock*)
+ 'rcu_lock (*rcu_read_lock*) ||
+ 'rcu_unlock (*rcu_read_unlock*) ||
+ 'sync_rcu (*synchronize_rcu*) ||
+ 'before_atomic (*smp_mb__before_atomic*) ||
+ 'after_atomic (*smp_mb__after_atomic*) ||
+ 'after_spinlock (*smp_mb__after_spinlock*)
instructions F[Barriers]
(* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
let matched = let rec
- unmatched-locks = Rcu-lock \ domain(matched)
- and unmatched-unlocks = Rcu-unlock \ range(matched)
+ unmatched-locks = Rcu_lock \ domain(matched)
+ and unmatched-unlocks = Rcu_unlock \ range(matched)
and unmatched = unmatched-locks | unmatched-unlocks
and unmatched-po = [unmatched] ; po ; [unmatched]
and unmatched-locks-to-unlocks =
@@ -46,8 +46,8 @@ let matched = let rec
in matched
(* Validate nesting *)
-flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
-flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_lock \ domain(matched) as unbalanced-rcu-locking
+flag ~empty Rcu_unlock \ range(matched) as unbalanced-rcu-locking
(* Outermost level of nesting only *)
let crit = matched \ (po^-1 ; matched ; po^-1)
diff --git a/tools/memory-model/linux-kernel.cat
b/tools/memory-model/linux-kernel.cat
index f0d27f8..d0085d5 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -29,10 +29,10 @@ let rb-dep = [R] ; fencerel(Rb_dep) ; [R]
let rmb = [R \ Noreturn] ; fencerel(Rmb) ; [R \ Noreturn]
let wmb = [W] ; fencerel(Wmb) ; [W]
let mb = ([M] ; fencerel(Mb) ; [M]) |
- ([M] ; fencerel(Before-atomic) ; [RMW] ; po? ; [M]) |
- ([M] ; po? ; [RMW] ; fencerel(After-atomic) ; [M]) |
- ([M] ; po? ; [LKW] ; fencerel(After-spinlock) ; [M])
-let gp = po ; [Sync-rcu] ; po?
+ ([M] ; fencerel(Before_atomic) ; [RMW] ; po? ; [M]) |
+ ([M] ; po? ; [RMW] ; fencerel(After_atomic) ; [M]) |
+ ([M] ; po? ; [LKW] ; fencerel(After_spinlock) ; [M])
+let gp = po ; [Sync_rcu] ; po?
let strong-fence = mb | gp
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index f5a1eb0..fc08371 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -21,9 +21,9 @@ smp_mb() { __fence{mb} ; }
smp_rmb() { __fence{rmb} ; }
smp_wmb() { __fence{wmb} ; }
smp_read_barrier_depends() { __fence{rb_dep}; }
-smp_mb__before_atomic() { __fence{before-atomic} ; }
-smp_mb__after_atomic() { __fence{after-atomic} ; }
-smp_mb__after_spinlock() { __fence{after-spinlock} ; }
+smp_mb__before_atomic() { __fence{before_atomic} ; }
+smp_mb__after_atomic() { __fence{after_atomic} ; }
+smp_mb__after_spinlock() { __fence{after_spinlock} ; }
// Exchange
xchg(X,V) __xchg{mb}(X,V)
@@ -41,10 +41,10 @@ spin_unlock(X) { __unlock(X) ; }
spin_trylock(X) __trylock(X)
// RCU
-rcu_read_lock() { __fence{rcu-lock}; }
-rcu_read_unlock() { __fence{rcu-unlock};}
-synchronize_rcu() { __fence{sync-rcu}; }
-synchronize_rcu_expedited() { __fence{sync-rcu}; }
+rcu_read_lock() { __fence{rcu_lock}; }
+rcu_read_unlock() { __fence{rcu_unlock};}
+synchronize_rcu() { __fence{sync_rcu}; }
+synchronize_rcu_expedited() { __fence{sync_rcu}; }
// Atomic
atomic_read(X) READ_ONCE(*X)
--
2.7.4
Re: [PATCH RFC tools/lkmm] Miscellaneous fixes
On 2018/02/09 23:18, Paul E. McKenney wrote: > Hello! > > This RFC series adds some miscellaneous updates to the Linux kernel > memory model: > > 1.Clarify the origin and scope of the tool name to avoid confusion > between "memory model" and "memory management", courtesy of > Andrea Parri. > > 2.Move the maintainer list for LKMM to the main MAINTAINERS file, > courtesy of Andrea Parri. > > 3.Add memory-barriers.txt to the LKMM MAINTAINERS entry, courtesy > of Andrea Parri. > > 4.Add comments explaining the purpose of the various litmus tests. > > 5.Fix puntuation errors in litmus-tests/README. > > 6.Add LKMM acronym to MAINTAINERS entry. If there are no objections, > this will be squashed with #3 above. > > 7.Add Akira Yokosawa as an LKMM reviewer. > > 8-10. Replace underscores with hyphens for smp_mb__*() workings. Note that > this patch leaves rb_dep alone because the underscore is set by herd7. > If there are no objections, these will be squashed together. Paul, Patches 8-10 made the problem even worse with herd7 7.47. I'll submit an alternative patch in reply to this message. Thanks, Akira > > Thanx, Paul > > > > /tools/memory-model/MAINTAINERS > | 15 --- > b/MAINTAINERS > | 20 +- > b/tools/memory-model/MAINTAINERS > |2 - > b/tools/memory-model/README > | 14 +++ > b/tools/memory-model/linux-kernel.bell > |8 ++-- > b/tools/memory-model/linux-kernel.cat > |8 ++-- > b/tools/memory-model/linux-kernel.def > |6 +-- > b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus > |7 +++ > b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > |7 +++ > b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus > |7 +++ > b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus > |7 +++ > b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus > | 10 + > b/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus > | 10 + > b/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus > |9 > > b/tools/memory-model/litmus-tests/ISA2+pooncerelease+poacquirerelease+poacquireonce.litmus > | 11 + > b/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus > | 11 + > b/tools/memory-model/litmus-tests/LB+poacquireonce+pooncerelease.litmus > |8 > b/tools/memory-model/litmus-tests/LB+poonceonces.litmus > |7 +++ > b/tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus > | 11 + > b/tools/memory-model/litmus-tests/MP+polocks.litmus > | 11 + > b/tools/memory-model/litmus-tests/MP+poonceonces.litmus > |7 +++ > b/tools/memory-model/litmus-tests/MP+pooncerelease+poacquireonce.litmus > |8 > b/tools/memory-model/litmus-tests/MP+porevlocks.litmus > | 11 + > b/tools/memory-model/litmus-tests/MP+wmbonceonce+rmbonceonce.litmus > |8 > b/tools/memory-model/litmus-tests/R+mbonceonces.litmus > |9 > b/tools/memory-model/litmus-tests/R+poonceonces.litmus > |8 > b/tools/memory-model/litmus-tests/README > |4 +- > b/tools/memory-model/litmus-tests/S+poonceonces.litmus > |9 > b/tools/memory-model/litmus-tests/S+wmbonceonce+poacquireonce.litmus > |7 +++ > b/tools/memory-model/litmus-tests/SB+mbonceonces.litmus > |9 > b/tools/memory-model/litmus-tests/SB+poonceonces.litmus
Re: [PATCH RFC tools/lkmm] Miscellaneous fixes
On 2018/02/09 23:18, Paul E. McKenney wrote: > Hello! > > This RFC series adds some miscellaneous updates to the Linux kernel > memory model: > > 1.Clarify the origin and scope of the tool name to avoid confusion > between "memory model" and "memory management", courtesy of > Andrea Parri. > > 2.Move the maintainer list for LKMM to the main MAINTAINERS file, > courtesy of Andrea Parri. > > 3.Add memory-barriers.txt to the LKMM MAINTAINERS entry, courtesy > of Andrea Parri. > > 4.Add comments explaining the purpose of the various litmus tests. > > 5.Fix puntuation errors in litmus-tests/README. > > 6.Add LKMM acronym to MAINTAINERS entry. If there are no objections, > this will be squashed with #3 above. > > 7.Add Akira Yokosawa as an LKMM reviewer. > > 8-10. Replace underscores with hyphens for smp_mb__*() workings. Note that > this patch leaves rb_dep alone because the underscore is set by herd7. > If there are no objections, these will be squashed together. Paul, Patches 8-10 made the problem even worse with herd7 7.47. I'll submit an alternative patch in reply to this message. Thanks, Akira > > Thanx, Paul > > > > /tools/memory-model/MAINTAINERS > | 15 --- > b/MAINTAINERS > | 20 +- > b/tools/memory-model/MAINTAINERS > |2 - > b/tools/memory-model/README > | 14 +++ > b/tools/memory-model/linux-kernel.bell > |8 ++-- > b/tools/memory-model/linux-kernel.cat > |8 ++-- > b/tools/memory-model/linux-kernel.def > |6 +-- > b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus > |7 +++ > b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > |7 +++ > b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus > |7 +++ > b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus > |7 +++ > b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus > | 10 + > b/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus > | 10 + > b/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus > |9 > > b/tools/memory-model/litmus-tests/ISA2+pooncerelease+poacquirerelease+poacquireonce.litmus > | 11 + > b/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus > | 11 + > b/tools/memory-model/litmus-tests/LB+poacquireonce+pooncerelease.litmus > |8 > b/tools/memory-model/litmus-tests/LB+poonceonces.litmus > |7 +++ > b/tools/memory-model/litmus-tests/MP+onceassign+derefonce.litmus > | 11 + > b/tools/memory-model/litmus-tests/MP+polocks.litmus > | 11 + > b/tools/memory-model/litmus-tests/MP+poonceonces.litmus > |7 +++ > b/tools/memory-model/litmus-tests/MP+pooncerelease+poacquireonce.litmus > |8 > b/tools/memory-model/litmus-tests/MP+porevlocks.litmus > | 11 + > b/tools/memory-model/litmus-tests/MP+wmbonceonce+rmbonceonce.litmus > |8 > b/tools/memory-model/litmus-tests/R+mbonceonces.litmus > |9 > b/tools/memory-model/litmus-tests/R+poonceonces.litmus > |8 > b/tools/memory-model/litmus-tests/README > |4 +- > b/tools/memory-model/litmus-tests/S+poonceonces.litmus > |9 > b/tools/memory-model/litmus-tests/S+wmbonceonce+poacquireonce.litmus > |7 +++ > b/tools/memory-model/litmus-tests/SB+mbonceonces.litmus > |9 > b/tools/memory-model/litmus-tests/SB+poonceonces.litmus
Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"
On 2018/02/09 23:29, Paul E. McKenney wrote:
> On Fri, Feb 09, 2018 at 01:50:51PM +0100, Andrea Parri wrote:
>> On Fri, Feb 09, 2018 at 04:31:00AM -0800, Paul E. McKenney wrote:
>>> On Sun, Feb 04, 2018 at 07:37:08PM +0100, Andrea Parri wrote:
>>>> Hi Akira,
>>>>
>>>> On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote:
>>>>> Hi Paul,
>>>>> CC: Andrea
>>>>>
>>>>> This is intentionally off the list, as I was not cc'd in the thread.
>>>>> If you think it is worthwhile, could you help me join the thread by
>>>>> forwarding the following part as a reply to your message, plus CC: to me.
>>>>
>>>> [CCing lists and other people]
>>>>
>>>>
>>>>>
>>>>> On Fri, Feb 02, 2018 at 17:21:03AM -0800, Paul E. McKenney wrote:
>>>>>> On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
>>>>>>> Recent efforts led to the specification of a memory consistency model
>>>>>>> for the Linux kernel [1], which "can (roughly speaking) be thought of
>>>>>>> as an automated version of memory-barriers.txt" and which is (in turn)
>>>>>>> "accompanied by extensive documentation on its use and its design".
>>>>>>>
>>>>>>> Make sure that the (occasional) reader of memory-barriers.txt will be
>>>>>>> aware of these developments.
>>>>>>>
>>>>>>> [1] https://marc.info/?l=linux-kernel=151687290114799=2
>>>>>>>
>>>>>>> Signed-off-by: Andrea Parri <parri.andrea@x>
>>>>>>
>>>>>> I am inclined to pull in something along these lines, but would like
>>>>>> some feedback on the wording, especially how "official" we want to
>>>>>> make the memory model to be.
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> The change log of commit e7720af5f9ac ("locking/Documentation: Add
>>>>> disclaimer") says:
>>>>>
>>>>> It appears people are reading this document as a requirements list for
>>>>> building hardware. This is not the intent of this document. Nor is it
>>>>> particularly suited for this purpose.
>>>>>
>>>>> The primary purpose of this document is our collective attempt to
>>>>> define
>>>>> a set of primitives that (hopefully) allow us to write correct code on
>>>>> the myriad of SMP platforms Linux supports.
>>>>>
>>>>> Its a definite work in progress as our understanding of these
>>>>> platforms,
>>>>> and memory ordering in general, progresses.
>>>>>
>>>>> Nor does being mentioned in this document mean we think its a
>>>>> particularly good idea; the data dependency barrier required by Alpha
>>>>> being a prime example. Yes we have it, no you're insane to require it
>>>>> when building new hardware.
>>>>>
>>>>> My take on the Linux Kernel memory-consistency model is a supplement of
>>>>> memory-barriers.txt and the disclaimer also applies to the memory model.
>>>>>
>>>>>>
>>>>>> If I don't hear otherwise in a couple of days, I will pull this as is.
>>>>>>
>>>>>> Thanx, Paul
>>>>>>
>>>>>>> ---
>>>>>>> Documentation/memory-barriers.txt | 4 +++-
>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/Documentation/memory-barriers.txt
>>>>>>> b/Documentation/memory-barriers.txt
>>>>>>> index a863009849a3b..8cc3f098f4a7d 100644
>>>>>>> --- a/Documentation/memory-barriers.txt
>>>>>>> +++ b/Documentation/memory-barriers.txt
>>>>>>> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers
>>>>>>> provided by Linux, but
>>>>>>> in case of any doubt (and there are many) please ask.
>>>>>>>
>>>>>>> To repeat, this document is not a specification of what Linux expects
>>>>>>> from
Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"
On 2018/02/09 23:29, Paul E. McKenney wrote:
> On Fri, Feb 09, 2018 at 01:50:51PM +0100, Andrea Parri wrote:
>> On Fri, Feb 09, 2018 at 04:31:00AM -0800, Paul E. McKenney wrote:
>>> On Sun, Feb 04, 2018 at 07:37:08PM +0100, Andrea Parri wrote:
>>>> Hi Akira,
>>>>
>>>> On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote:
>>>>> Hi Paul,
>>>>> CC: Andrea
>>>>>
>>>>> This is intentionally off the list, as I was not cc'd in the thread.
>>>>> If you think it is worthwhile, could you help me join the thread by
>>>>> forwarding the following part as a reply to your message, plus CC: to me.
>>>>
>>>> [CCing lists and other people]
>>>>
>>>>
>>>>>
>>>>> On Fri, Feb 02, 2018 at 17:21:03AM -0800, Paul E. McKenney wrote:
>>>>>> On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
>>>>>>> Recent efforts led to the specification of a memory consistency model
>>>>>>> for the Linux kernel [1], which "can (roughly speaking) be thought of
>>>>>>> as an automated version of memory-barriers.txt" and which is (in turn)
>>>>>>> "accompanied by extensive documentation on its use and its design".
>>>>>>>
>>>>>>> Make sure that the (occasional) reader of memory-barriers.txt will be
>>>>>>> aware of these developments.
>>>>>>>
>>>>>>> [1] https://marc.info/?l=linux-kernel=151687290114799=2
>>>>>>>
>>>>>>> Signed-off-by: Andrea Parri
>>>>>>
>>>>>> I am inclined to pull in something along these lines, but would like
>>>>>> some feedback on the wording, especially how "official" we want to
>>>>>> make the memory model to be.
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> The change log of commit e7720af5f9ac ("locking/Documentation: Add
>>>>> disclaimer") says:
>>>>>
>>>>> It appears people are reading this document as a requirements list for
>>>>> building hardware. This is not the intent of this document. Nor is it
>>>>> particularly suited for this purpose.
>>>>>
>>>>> The primary purpose of this document is our collective attempt to
>>>>> define
>>>>> a set of primitives that (hopefully) allow us to write correct code on
>>>>> the myriad of SMP platforms Linux supports.
>>>>>
>>>>> Its a definite work in progress as our understanding of these
>>>>> platforms,
>>>>> and memory ordering in general, progresses.
>>>>>
>>>>> Nor does being mentioned in this document mean we think its a
>>>>> particularly good idea; the data dependency barrier required by Alpha
>>>>> being a prime example. Yes we have it, no you're insane to require it
>>>>> when building new hardware.
>>>>>
>>>>> My take on the Linux Kernel memory-consistency model is a supplement of
>>>>> memory-barriers.txt and the disclaimer also applies to the memory model.
>>>>>
>>>>>>
>>>>>> If I don't hear otherwise in a couple of days, I will pull this as is.
>>>>>>
>>>>>> Thanx, Paul
>>>>>>
>>>>>>> ---
>>>>>>> Documentation/memory-barriers.txt | 4 +++-
>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/Documentation/memory-barriers.txt
>>>>>>> b/Documentation/memory-barriers.txt
>>>>>>> index a863009849a3b..8cc3f098f4a7d 100644
>>>>>>> --- a/Documentation/memory-barriers.txt
>>>>>>> +++ b/Documentation/memory-barriers.txt
>>>>>>> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers
>>>>>>> provided by Linux, but
>>>>>>> in case of any doubt (and there are many) please ask.
>>>>>>>
>>>>>>> To repeat, this document is not a specification of what Linux expects
>>>>>>> from
>>>>>>> -hardware.
>>
Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"
On 2018/02/09 21:50, Andrea Parri wrote:
> On Fri, Feb 09, 2018 at 04:31:00AM -0800, Paul E. McKenney wrote:
>> On Sun, Feb 04, 2018 at 07:37:08PM +0100, Andrea Parri wrote:
>>> Hi Akira,
>>>
>>> On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote:
>>>> Hi Paul,
>>>> CC: Andrea
>>>>
>>>> This is intentionally off the list, as I was not cc'd in the thread.
>>>> If you think it is worthwhile, could you help me join the thread by
>>>> forwarding the following part as a reply to your message, plus CC: to me.
>>>
>>> [CCing lists and other people]
>>>
>>>
>>>>
>>>> On Fri, Feb 02, 2018 at 17:21:03AM -0800, Paul E. McKenney wrote:
>>>>> On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
>>>>>> Recent efforts led to the specification of a memory consistency model
>>>>>> for the Linux kernel [1], which "can (roughly speaking) be thought of
>>>>>> as an automated version of memory-barriers.txt" and which is (in turn)
>>>>>> "accompanied by extensive documentation on its use and its design".
>>>>>>
>>>>>> Make sure that the (occasional) reader of memory-barriers.txt will be
>>>>>> aware of these developments.
>>>>>>
>>>>>> [1] https://marc.info/?l=linux-kernel=151687290114799=2
>>>>>>
>>>>>> Signed-off-by: Andrea Parri <parri.andrea@x>
>>>>>
>>>>> I am inclined to pull in something along these lines, but would like
>>>>> some feedback on the wording, especially how "official" we want to
>>>>> make the memory model to be.
>>>>>
>>>>> Thoughts?
>>>>
>>>> The change log of commit e7720af5f9ac ("locking/Documentation: Add
>>>> disclaimer") says:
>>>>
>>>> It appears people are reading this document as a requirements list for
>>>> building hardware. This is not the intent of this document. Nor is it
>>>> particularly suited for this purpose.
>>>>
>>>> The primary purpose of this document is our collective attempt to
>>>> define
>>>> a set of primitives that (hopefully) allow us to write correct code on
>>>> the myriad of SMP platforms Linux supports.
>>>>
>>>> Its a definite work in progress as our understanding of these
>>>> platforms,
>>>> and memory ordering in general, progresses.
>>>>
>>>> Nor does being mentioned in this document mean we think its a
>>>> particularly good idea; the data dependency barrier required by Alpha
>>>> being a prime example. Yes we have it, no you're insane to require it
>>>> when building new hardware.
>>>>
>>>> My take on the Linux Kernel memory-consistency model is a supplement of
>>>> memory-barriers.txt and the disclaimer also applies to the memory model.
>>>>
>>>>>
>>>>> If I don't hear otherwise in a couple of days, I will pull this as is.
>>>>>
>>>>> Thanx, Paul
>>>>>
>>>>>> ---
>>>>>> Documentation/memory-barriers.txt | 4 +++-
>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/memory-barriers.txt
>>>>>> b/Documentation/memory-barriers.txt
>>>>>> index a863009849a3b..8cc3f098f4a7d 100644
>>>>>> --- a/Documentation/memory-barriers.txt
>>>>>> +++ b/Documentation/memory-barriers.txt
>>>>>> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers
>>>>>> provided by Linux, but
>>>>>> in case of any doubt (and there are many) please ask.
>>>>>>
>>>>>> To repeat, this document is not a specification of what Linux expects
>>>>>> from
>>>>>> -hardware.
>>>>>> +hardware. For such a specification, in the form of a memory consistency
>>>>>> +model, and for documentation about its usage and its design, the reader
>>>>>> is
>>>>>> +referred to "tools/memory-model/".
>>>>>>
>>>>
>>>> Adding cross-refer
Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"
On 2018/02/09 21:50, Andrea Parri wrote:
> On Fri, Feb 09, 2018 at 04:31:00AM -0800, Paul E. McKenney wrote:
>> On Sun, Feb 04, 2018 at 07:37:08PM +0100, Andrea Parri wrote:
>>> Hi Akira,
>>>
>>> On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote:
>>>> Hi Paul,
>>>> CC: Andrea
>>>>
>>>> This is intentionally off the list, as I was not cc'd in the thread.
>>>> If you think it is worthwhile, could you help me join the thread by
>>>> forwarding the following part as a reply to your message, plus CC: to me.
>>>
>>> [CCing lists and other people]
>>>
>>>
>>>>
>>>> On Fri, Feb 02, 2018 at 17:21:03AM -0800, Paul E. McKenney wrote:
>>>>> On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
>>>>>> Recent efforts led to the specification of a memory consistency model
>>>>>> for the Linux kernel [1], which "can (roughly speaking) be thought of
>>>>>> as an automated version of memory-barriers.txt" and which is (in turn)
>>>>>> "accompanied by extensive documentation on its use and its design".
>>>>>>
>>>>>> Make sure that the (occasional) reader of memory-barriers.txt will be
>>>>>> aware of these developments.
>>>>>>
>>>>>> [1] https://marc.info/?l=linux-kernel=151687290114799=2
>>>>>>
>>>>>> Signed-off-by: Andrea Parri
>>>>>
>>>>> I am inclined to pull in something along these lines, but would like
>>>>> some feedback on the wording, especially how "official" we want to
>>>>> make the memory model to be.
>>>>>
>>>>> Thoughts?
>>>>
>>>> The change log of commit e7720af5f9ac ("locking/Documentation: Add
>>>> disclaimer") says:
>>>>
>>>> It appears people are reading this document as a requirements list for
>>>> building hardware. This is not the intent of this document. Nor is it
>>>> particularly suited for this purpose.
>>>>
>>>> The primary purpose of this document is our collective attempt to
>>>> define
>>>> a set of primitives that (hopefully) allow us to write correct code on
>>>> the myriad of SMP platforms Linux supports.
>>>>
>>>> Its a definite work in progress as our understanding of these
>>>> platforms,
>>>> and memory ordering in general, progresses.
>>>>
>>>> Nor does being mentioned in this document mean we think its a
>>>> particularly good idea; the data dependency barrier required by Alpha
>>>> being a prime example. Yes we have it, no you're insane to require it
>>>> when building new hardware.
>>>>
>>>> My take on the Linux Kernel memory-consistency model is a supplement of
>>>> memory-barriers.txt and the disclaimer also applies to the memory model.
>>>>
>>>>>
>>>>> If I don't hear otherwise in a couple of days, I will pull this as is.
>>>>>
>>>>> Thanx, Paul
>>>>>
>>>>>> ---
>>>>>> Documentation/memory-barriers.txt | 4 +++-
>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/memory-barriers.txt
>>>>>> b/Documentation/memory-barriers.txt
>>>>>> index a863009849a3b..8cc3f098f4a7d 100644
>>>>>> --- a/Documentation/memory-barriers.txt
>>>>>> +++ b/Documentation/memory-barriers.txt
>>>>>> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers
>>>>>> provided by Linux, but
>>>>>> in case of any doubt (and there are many) please ask.
>>>>>>
>>>>>> To repeat, this document is not a specification of what Linux expects
>>>>>> from
>>>>>> -hardware.
>>>>>> +hardware. For such a specification, in the form of a memory consistency
>>>>>> +model, and for documentation about its usage and its design, the reader
>>>>>> is
>>>>>> +referred to "tools/memory-model/".
>>>>>>
>>>>
>>>> Adding cross-reference in this way can _we
