Hello!
This series adds a few atomic operations and some documentation:
1. tools/memory-model: Add atomic_and()/or()/xor() and add_negative,
courtesy of Puranjay Mohan.
2. tools/memory-model: Add atomic_andnot() with its variants,
courtesy of Puranjay Mohan.
3. tools/memory-model: Add KCSAN LF mentorship session citation.
Thanx, Paul
------------------------------------------------------------------------
b/tools/memory-model/Documentation/access-marking.txt | 10 ++++++--
b/tools/memory-model/linux-kernel.def | 21 ++++++++++++++++++
tools/memory-model/linux-kernel.def | 6 +++++
3 files changed, 34 insertions(+), 3 deletions(-)
From: Puranjay Mohan <[email protected]>
Pull-849[1] added the support of '&', '|', and '^' to the herd7 tool's
atomics operations.
Use these in linux-kernel.def to implement atomic_and()/or()/xor() with
all their ordering variants.
atomic_add_negative() is already available so add its acquire, release,
and relaxed ordering variants.
[1] https://github.com/herd/herdtools7/pull/849
Signed-off-by: Puranjay Mohan <[email protected]>
Acked-by: Andrea Parri <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: David Howells <[email protected]>
Cc: Jade Alglave <[email protected]>
Cc: Luc Maranget <[email protected]>
Cc: Akira Yokosawa <[email protected]>
Cc: Daniel Lustig <[email protected]>
Cc: Joel Fernandes <[email protected]>
Cc: <[email protected]>
---
tools/memory-model/linux-kernel.def | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/tools/memory-model/linux-kernel.def b/tools/memory-model/linux-kernel.def
index 88a39601f5256..d1f11930ec512 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -65,6 +65,9 @@ atomic_set_release(X,V) { smp_store_release(X,V); }
atomic_add(V,X) { __atomic_op(X,+,V); }
atomic_sub(V,X) { __atomic_op(X,-,V); }
+atomic_and(V,X) { __atomic_op(X,&,V); }
+atomic_or(V,X) { __atomic_op(X,|,V); }
+atomic_xor(V,X) { __atomic_op(X,^,V); }
atomic_inc(X) { __atomic_op(X,+,1); }
atomic_dec(X) { __atomic_op(X,-,1); }
@@ -77,6 +80,21 @@ atomic_fetch_add_relaxed(V,X) __atomic_fetch_op{once}(X,+,V)
atomic_fetch_add_acquire(V,X) __atomic_fetch_op{acquire}(X,+,V)
atomic_fetch_add_release(V,X) __atomic_fetch_op{release}(X,+,V)
+atomic_fetch_and(V,X) __atomic_fetch_op{mb}(X,&,V)
+atomic_fetch_and_relaxed(V,X) __atomic_fetch_op{once}(X,&,V)
+atomic_fetch_and_acquire(V,X) __atomic_fetch_op{acquire}(X,&,V)
+atomic_fetch_and_release(V,X) __atomic_fetch_op{release}(X,&,V)
+
+atomic_fetch_or(V,X) __atomic_fetch_op{mb}(X,|,V)
+atomic_fetch_or_relaxed(V,X) __atomic_fetch_op{once}(X,|,V)
+atomic_fetch_or_acquire(V,X) __atomic_fetch_op{acquire}(X,|,V)
+atomic_fetch_or_release(V,X) __atomic_fetch_op{release}(X,|,V)
+
+atomic_fetch_xor(V,X) __atomic_fetch_op{mb}(X,^,V)
+atomic_fetch_xor_relaxed(V,X) __atomic_fetch_op{once}(X,^,V)
+atomic_fetch_xor_acquire(V,X) __atomic_fetch_op{acquire}(X,^,V)
+atomic_fetch_xor_release(V,X) __atomic_fetch_op{release}(X,^,V)
+
atomic_inc_return(X) __atomic_op_return{mb}(X,+,1)
atomic_inc_return_relaxed(X) __atomic_op_return{once}(X,+,1)
atomic_inc_return_acquire(X) __atomic_op_return{acquire}(X,+,1)
@@ -117,3 +135,6 @@ atomic_sub_and_test(V,X) __atomic_op_return{mb}(X,-,V) == 0
atomic_dec_and_test(X) __atomic_op_return{mb}(X,-,1) == 0
atomic_inc_and_test(X) __atomic_op_return{mb}(X,+,1) == 0
atomic_add_negative(V,X) __atomic_op_return{mb}(X,+,V) < 0
+atomic_add_negative_relaxed(V,X) __atomic_op_return{once}(X,+,V) < 0
+atomic_add_negative_acquire(V,X) __atomic_op_return{acquire}(X,+,V) < 0
+atomic_add_negative_release(V,X) __atomic_op_return{release}(X,+,V) < 0
--
2.40.1
Add a citation to Marco's LF mentorship session presentation entitled
"The Kernel Concurrency Sanitizer"
[ paulmck: Apply Marco Elver feedback. ]
Reported-by: Marco Elver <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Andrea Parri <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Boqun Feng <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: David Howells <[email protected]>
Cc: Jade Alglave <[email protected]>
Cc: Luc Maranget <[email protected]>
Cc: Akira Yokosawa <[email protected]>
Cc: Daniel Lustig <[email protected]>
Cc: Joel Fernandes <[email protected]>
Cc: <[email protected]>
---
tools/memory-model/Documentation/access-marking.txt | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/memory-model/Documentation/access-marking.txt b/tools/memory-model/Documentation/access-marking.txt
index 65778222183e3..f531b0837356b 100644
--- a/tools/memory-model/Documentation/access-marking.txt
+++ b/tools/memory-model/Documentation/access-marking.txt
@@ -6,7 +6,8 @@ normal accesses to shared memory, that is "normal" as in accesses that do
not use read-modify-write atomic operations. It also describes how to
document these accesses, both with comments and with special assertions
processed by the Kernel Concurrency Sanitizer (KCSAN). This discussion
-builds on an earlier LWN article [1].
+builds on an earlier LWN article [1] and Linux Foundation mentorship
+session [2].
ACCESS-MARKING OPTIONS
@@ -31,7 +32,7 @@ example:
WRITE_ONCE(a, b + data_race(c + d) + READ_ONCE(e));
Neither plain C-language accesses nor data_race() (#1 and #2 above) place
-any sort of constraint on the compiler's choice of optimizations [2].
+any sort of constraint on the compiler's choice of optimizations [3].
In contrast, READ_ONCE() and WRITE_ONCE() (#3 and #4 above) restrict the
compiler's use of code-motion and common-subexpression optimizations.
Therefore, if a given access is involved in an intentional data race,
@@ -594,5 +595,8 @@ REFERENCES
[1] "Concurrency bugs should fear the big bad data-race detector (part 2)"
https://lwn.net/Articles/816854/
-[2] "Who's afraid of a big bad optimizing compiler?"
+[2] "The Kernel Concurrency Sanitizer"
+ https://www.linuxfoundation.org/webinars/the-kernel-concurrency-sanitizer
+
+[3] "Who's afraid of a big bad optimizing compiler?"
https://lwn.net/Articles/793253/
--
2.40.1
From: Puranjay Mohan <[email protected]>
Pull-855[1] added the support of atomic_andnot() to the herd tool. Use
this to add the implementation in the LKMM. All of the ordering variants
are also added.
Here is a small litmus-test that uses this operation:
C andnot
{
atomic_t u = ATOMIC_INIT(7);
}
P0(atomic_t *u)
{
r0 = atomic_fetch_andnot(3, u);
r1 = READ_ONCE(*u);
}
exists (0:r0=7 /\ 0:r1=4)
Test andnot Allowed
States 1
0:r0=7; 0:r1=4;
Ok
Witnesses
Positive: 1 Negative: 0
Condition exists (0:r0=7 /\ 0:r1=4)
Observation andnot Always 1 0
Time andnot 0.00
Hash=78f011a0b5a0c65fa1cf106fcd62c845
[1] https://github.com/herd/herdtools7/pull/855
Signed-off-by: Puranjay Mohan <[email protected]>
Acked-by: Andrea Parri <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Boqun Feng <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: David Howells <[email protected]>
Cc: Jade Alglave <[email protected]>
Cc: Luc Maranget <[email protected]>
Cc: Akira Yokosawa <[email protected]>
Cc: Daniel Lustig <[email protected]>
Cc: Joel Fernandes <[email protected]>
Cc: <[email protected]>
---
tools/memory-model/linux-kernel.def | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/memory-model/linux-kernel.def b/tools/memory-model/linux-kernel.def
index d1f11930ec512..a12b96c547b7a 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -70,6 +70,7 @@ atomic_or(V,X) { __atomic_op(X,|,V); }
atomic_xor(V,X) { __atomic_op(X,^,V); }
atomic_inc(X) { __atomic_op(X,+,1); }
atomic_dec(X) { __atomic_op(X,-,1); }
+atomic_andnot(V,X) { __atomic_op(X,&~,V); }
atomic_add_return(V,X) __atomic_op_return{mb}(X,+,V)
atomic_add_return_relaxed(V,X) __atomic_op_return{once}(X,+,V)
@@ -138,3 +139,8 @@ atomic_add_negative(V,X) __atomic_op_return{mb}(X,+,V) < 0
atomic_add_negative_relaxed(V,X) __atomic_op_return{once}(X,+,V) < 0
atomic_add_negative_acquire(V,X) __atomic_op_return{acquire}(X,+,V) < 0
atomic_add_negative_release(V,X) __atomic_op_return{release}(X,+,V) < 0
+
+atomic_fetch_andnot(V,X) __atomic_fetch_op{mb}(X,&~,V)
+atomic_fetch_andnot_acquire(V,X) __atomic_fetch_op{acquire}(X,&~,V)
+atomic_fetch_andnot_release(V,X) __atomic_fetch_op{release}(X,&~,V)
+atomic_fetch_andnot_relaxed(V,X) __atomic_fetch_op{once}(X,&~,V)
--
2.40.1
On Tue, Jun 04, 2024 at 03:14:19PM -0700, Paul E. McKenney wrote:
> Add a citation to Marco's LF mentorship session presentation entitled
> "The Kernel Concurrency Sanitizer"
>
> [ paulmck: Apply Marco Elver feedback. ]
>
> Reported-by: Marco Elver <[email protected]>
> Signed-off-by: Paul E. McKenney <[email protected]>
Acked-by: Andrea Parri <[email protected]>
Andrea
Hi,
On Tue, 4 Jun 2024 15:14:17 -0700, Paul E. McKenney wrote:
> From: Puranjay Mohan <[email protected]>
>
> Pull-849[1] added the support of '&', '|', and '^' to the herd7 tool's
> atomics operations.
>
> Use these in linux-kernel.def to implement atomic_and()/or()/xor() with
> all their ordering variants.
>
> atomic_add_negative() is already available so add its acquire, release,
> and relaxed ordering variants.
>
> [1] https://github.com/herd/herdtools7/pull/849
>
> Signed-off-by: Puranjay Mohan <[email protected]>
> Acked-by: Andrea Parri <[email protected]>
> Reviewed-by: Boqun Feng <[email protected]>
> Signed-off-by: Paul E. McKenney <[email protected]>
> Cc: Alan Stern <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Nicholas Piggin <[email protected]>
> Cc: David Howells <[email protected]>
> Cc: Jade Alglave <[email protected]>
> Cc: Luc Maranget <[email protected]>
> Cc: Akira Yokosawa <[email protected]>
Pull-849 and Pull-855 at herdtools7 happened after the release of 7.57.
So I thought patches 1/3 and 2/3 needed to wait a next release of
herdtools7.
But these changes don't affect existing litmus tests.
So I don't oppose them to be merged into 6.11.
It's up to Paul!
Thanks, Akira
> Cc: Daniel Lustig <[email protected]>
> Cc: Joel Fernandes <[email protected]>
> Cc: <[email protected]>
On Tue, 4 Jun 2024 15:14:19 -0700, Paul E. McKenney wrote:
> Add a citation to Marco's LF mentorship session presentation entitled
> "The Kernel Concurrency Sanitizer"
>
> [ paulmck: Apply Marco Elver feedback. ]
>
> Reported-by: Marco Elver <[email protected]>
> Signed-off-by: Paul E. McKenney <[email protected]>
> Cc: Alan Stern <[email protected]>
> Cc: Andrea Parri <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Boqun Feng <[email protected]>
> Cc: Nicholas Piggin <[email protected]>
> Cc: David Howells <[email protected]>
> Cc: Jade Alglave <[email protected]>
> Cc: Luc Maranget <[email protected]>
> Cc: Akira Yokosawa <[email protected]>
Paul,
While reviewing this, I noticed that
tools/memory-model/Documentation/README has no mention of
access-marking.txt.
It has no mention of glossary.txt or locking.txt, either.
I'm not sure where are the right places in README for them.
Can you update it in a follow-up change?
Anyway, for this change,
Reviewed-by: Akira Yokosawa <[email protected]>
Thanks, Akira
> Cc: Daniel Lustig <[email protected]>
> Cc: Joel Fernandes <[email protected]>
> Cc: <[email protected]>
> ---
On Wed, Jun 05, 2024 at 10:57:27AM +0900, Akira Yokosawa wrote:
> On Tue, 4 Jun 2024 15:14:19 -0700, Paul E. McKenney wrote:
> > Add a citation to Marco's LF mentorship session presentation entitled
> > "The Kernel Concurrency Sanitizer"
> >
> > [ paulmck: Apply Marco Elver feedback. ]
> >
> > Reported-by: Marco Elver <[email protected]>
> > Signed-off-by: Paul E. McKenney <[email protected]>
> > Cc: Alan Stern <[email protected]>
> > Cc: Andrea Parri <[email protected]>
> > Cc: Will Deacon <[email protected]>
> > Cc: Peter Zijlstra <[email protected]>
> > Cc: Boqun Feng <[email protected]>
> > Cc: Nicholas Piggin <[email protected]>
> > Cc: David Howells <[email protected]>
> > Cc: Jade Alglave <[email protected]>
> > Cc: Luc Maranget <[email protected]>
> > Cc: Akira Yokosawa <[email protected]>
>
> Paul,
>
> While reviewing this, I noticed that
> tools/memory-model/Documentation/README has no mention of
> access-marking.txt.
>
> It has no mention of glossary.txt or locking.txt, either.
>
> I'm not sure where are the right places in README for them.
> Can you update it in a follow-up change?
>
> Anyway, for this change,
>
> Reviewed-by: Akira Yokosawa <[email protected]>
Thank you, and good catch! Does the patch below look appropriate?
Thanx, Paul
------------------------------------------------------------------------
commit 834b22ba762fb59024843a64554d38409aaa82ec
Author: Paul E. McKenney <[email protected]>
Date: Tue Jun 4 20:59:35 2024 -0700
tools/memory-model: Add access-marking.txt to README
Given that access-marking.txt exists, this commit makes it easier to find.
Reported-by: Akira Yokosawa <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
diff --git a/tools/memory-model/Documentation/README b/tools/memory-model/Documentation/README
index db90a26dbdf40..304162743a5b8 100644
--- a/tools/memory-model/Documentation/README
+++ b/tools/memory-model/Documentation/README
@@ -47,6 +47,10 @@ DESCRIPTION OF FILES
README
This file.
+access-marking.txt
+ Guidelines for marking intentionally concurrent accesses to
+ shared memory.
+
cheatsheet.txt
Quick-reference guide to the Linux-kernel memory model.
On Wed, Jun 05, 2024 at 01:11:45AM +0200, Andrea Parri wrote:
> On Tue, Jun 04, 2024 at 03:14:19PM -0700, Paul E. McKenney wrote:
> > Add a citation to Marco's LF mentorship session presentation entitled
> > "The Kernel Concurrency Sanitizer"
> >
> > [ paulmck: Apply Marco Elver feedback. ]
> >
> > Reported-by: Marco Elver <[email protected]>
> > Signed-off-by: Paul E. McKenney <[email protected]>
>
> Acked-by: Andrea Parri <[email protected]>
Thank you! I will apply this along with Akira's on my next rebase.
Thanx, Paul
On Wed, Jun 05, 2024 at 09:27:12AM +0900, Akira Yokosawa wrote:
> Hi,
>
> On Tue, 4 Jun 2024 15:14:17 -0700, Paul E. McKenney wrote:
> > From: Puranjay Mohan <[email protected]>
> >
> > Pull-849[1] added the support of '&', '|', and '^' to the herd7 tool's
> > atomics operations.
> >
> > Use these in linux-kernel.def to implement atomic_and()/or()/xor() with
> > all their ordering variants.
> >
> > atomic_add_negative() is already available so add its acquire, release,
> > and relaxed ordering variants.
> >
> > [1] https://github.com/herd/herdtools7/pull/849
> >
> > Signed-off-by: Puranjay Mohan <[email protected]>
> > Acked-by: Andrea Parri <[email protected]>
> > Reviewed-by: Boqun Feng <[email protected]>
> > Signed-off-by: Paul E. McKenney <[email protected]>
> > Cc: Alan Stern <[email protected]>
> > Cc: Will Deacon <[email protected]>
> > Cc: Peter Zijlstra <[email protected]>
> > Cc: Nicholas Piggin <[email protected]>
> > Cc: David Howells <[email protected]>
> > Cc: Jade Alglave <[email protected]>
> > Cc: Luc Maranget <[email protected]>
> > Cc: Akira Yokosawa <[email protected]>
>
> Pull-849 and Pull-855 at herdtools7 happened after the release of 7.57.
> So I thought patches 1/3 and 2/3 needed to wait a next release of
> herdtools7.
>
> But these changes don't affect existing litmus tests.
> So I don't oppose them to be merged into 6.11.
>
> It's up to Paul!
I do not intend to send these to mainline before the herd7 changes are
officially released. But why not be optimistic? Hence sending the
patches for v6.11.
If the herd7 release is not forthcoming in time for the next merge window,
I will rebase the documentation update underneath the two RMW patches,
and send only the documentation update.
But maybe I should do that rebase sooner rather than later... Less
opportunity to forget that way.
Thanx, Paul
On Wed, 5 Jun 2024 at 00:14, Paul E. McKenney <[email protected]> wrote:
>
> Add a citation to Marco's LF mentorship session presentation entitled
> "The Kernel Concurrency Sanitizer"
>
> [ paulmck: Apply Marco Elver feedback. ]
>
> Reported-by: Marco Elver <[email protected]>
> Signed-off-by: Paul E. McKenney <[email protected]>
Acked-by: Marco Elver <[email protected]>
Thanks for adding.
> Cc: Alan Stern <[email protected]>
> Cc: Andrea Parri <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Boqun Feng <[email protected]>
> Cc: Nicholas Piggin <[email protected]>
> Cc: David Howells <[email protected]>
> Cc: Jade Alglave <[email protected]>
> Cc: Luc Maranget <[email protected]>
> Cc: Akira Yokosawa <[email protected]>
> Cc: Daniel Lustig <[email protected]>
> Cc: Joel Fernandes <[email protected]>
> Cc: <[email protected]>
> ---
> tools/memory-model/Documentation/access-marking.txt | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tools/memory-model/Documentation/access-marking.txt b/tools/memory-model/Documentation/access-marking.txt
> index 65778222183e3..f531b0837356b 100644
> --- a/tools/memory-model/Documentation/access-marking.txt
> +++ b/tools/memory-model/Documentation/access-marking.txt
> @@ -6,7 +6,8 @@ normal accesses to shared memory, that is "normal" as in accesses that do
> not use read-modify-write atomic operations. It also describes how to
> document these accesses, both with comments and with special assertions
> processed by the Kernel Concurrency Sanitizer (KCSAN). This discussion
> -builds on an earlier LWN article [1].
> +builds on an earlier LWN article [1] and Linux Foundation mentorship
> +session [2].
>
>
> ACCESS-MARKING OPTIONS
> @@ -31,7 +32,7 @@ example:
> WRITE_ONCE(a, b + data_race(c + d) + READ_ONCE(e));
>
> Neither plain C-language accesses nor data_race() (#1 and #2 above) place
> -any sort of constraint on the compiler's choice of optimizations [2].
> +any sort of constraint on the compiler's choice of optimizations [3].
> In contrast, READ_ONCE() and WRITE_ONCE() (#3 and #4 above) restrict the
> compiler's use of code-motion and common-subexpression optimizations.
> Therefore, if a given access is involved in an intentional data race,
> @@ -594,5 +595,8 @@ REFERENCES
> [1] "Concurrency bugs should fear the big bad data-race detector (part 2)"
> https://lwn.net/Articles/816854/
>
> -[2] "Who's afraid of a big bad optimizing compiler?"
> +[2] "The Kernel Concurrency Sanitizer"
> + https://www.linuxfoundation.org/webinars/the-kernel-concurrency-sanitizer
> +
> +[3] "Who's afraid of a big bad optimizing compiler?"
> https://lwn.net/Articles/793253/
> --
> 2.40.1
>
On Wed, Jun 05, 2024 at 09:52:38AM +0200, Marco Elver wrote:
> On Wed, 5 Jun 2024 at 00:14, Paul E. McKenney <[email protected]> wrote:
> >
> > Add a citation to Marco's LF mentorship session presentation entitled
> > "The Kernel Concurrency Sanitizer"
> >
> > [ paulmck: Apply Marco Elver feedback. ]
> >
> > Reported-by: Marco Elver <[email protected]>
> > Signed-off-by: Paul E. McKenney <[email protected]>
>
> Acked-by: Marco Elver <[email protected]>
>
> Thanks for adding.
I will apply your ack on my next rebase, thank you!
Thanx, Paul
> > Cc: Alan Stern <[email protected]>
> > Cc: Andrea Parri <[email protected]>
> > Cc: Will Deacon <[email protected]>
> > Cc: Peter Zijlstra <[email protected]>
> > Cc: Boqun Feng <[email protected]>
> > Cc: Nicholas Piggin <[email protected]>
> > Cc: David Howells <[email protected]>
> > Cc: Jade Alglave <[email protected]>
> > Cc: Luc Maranget <[email protected]>
> > Cc: Akira Yokosawa <[email protected]>
> > Cc: Daniel Lustig <[email protected]>
> > Cc: Joel Fernandes <[email protected]>
> > Cc: <[email protected]>
> > ---
> > tools/memory-model/Documentation/access-marking.txt | 10 +++++++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/memory-model/Documentation/access-marking.txt b/tools/memory-model/Documentation/access-marking.txt
> > index 65778222183e3..f531b0837356b 100644
> > --- a/tools/memory-model/Documentation/access-marking.txt
> > +++ b/tools/memory-model/Documentation/access-marking.txt
> > @@ -6,7 +6,8 @@ normal accesses to shared memory, that is "normal" as in accesses that do
> > not use read-modify-write atomic operations. It also describes how to
> > document these accesses, both with comments and with special assertions
> > processed by the Kernel Concurrency Sanitizer (KCSAN). This discussion
> > -builds on an earlier LWN article [1].
> > +builds on an earlier LWN article [1] and Linux Foundation mentorship
> > +session [2].
> >
> >
> > ACCESS-MARKING OPTIONS
> > @@ -31,7 +32,7 @@ example:
> > WRITE_ONCE(a, b + data_race(c + d) + READ_ONCE(e));
> >
> > Neither plain C-language accesses nor data_race() (#1 and #2 above) place
> > -any sort of constraint on the compiler's choice of optimizations [2].
> > +any sort of constraint on the compiler's choice of optimizations [3].
> > In contrast, READ_ONCE() and WRITE_ONCE() (#3 and #4 above) restrict the
> > compiler's use of code-motion and common-subexpression optimizations.
> > Therefore, if a given access is involved in an intentional data race,
> > @@ -594,5 +595,8 @@ REFERENCES
> > [1] "Concurrency bugs should fear the big bad data-race detector (part 2)"
> > https://lwn.net/Articles/816854/
> >
> > -[2] "Who's afraid of a big bad optimizing compiler?"
> > +[2] "The Kernel Concurrency Sanitizer"
> > + https://www.linuxfoundation.org/webinars/the-kernel-concurrency-sanitizer
> > +
> > +[3] "Who's afraid of a big bad optimizing compiler?"
> > https://lwn.net/Articles/793253/
> > --
> > 2.40.1
> >
On 2024/06/05 13:02, Paul E. McKenney wrote:
> On Wed, Jun 05, 2024 at 10:57:27AM +0900, Akira Yokosawa wrote:
>> On Tue, 4 Jun 2024 15:14:19 -0700, Paul E. McKenney wrote:
>>> Add a citation to Marco's LF mentorship session presentation entitled
>>> "The Kernel Concurrency Sanitizer"
>>>
>>> [ paulmck: Apply Marco Elver feedback. ]
>>>
>>> Reported-by: Marco Elver <[email protected]>
>>> Signed-off-by: Paul E. McKenney <[email protected]>
>>> Cc: Alan Stern <[email protected]>
>>> Cc: Andrea Parri <[email protected]>
>>> Cc: Will Deacon <[email protected]>
>>> Cc: Peter Zijlstra <[email protected]>
>>> Cc: Boqun Feng <[email protected]>
>>> Cc: Nicholas Piggin <[email protected]>
>>> Cc: David Howells <[email protected]>
>>> Cc: Jade Alglave <[email protected]>
>>> Cc: Luc Maranget <[email protected]>
>>> Cc: Akira Yokosawa <[email protected]>
>>
>> Paul,
>>
>> While reviewing this, I noticed that
>> tools/memory-model/Documentation/README has no mention of
>> access-marking.txt.
>>
>> It has no mention of glossary.txt or locking.txt, either.
>>
>> I'm not sure where are the right places in README for them.
>> Can you update it in a follow-up change?
>>
>> Anyway, for this change,
>>
>> Reviewed-by: Akira Yokosawa <[email protected]>
>
> Thank you, and good catch! Does the patch below look appropriate?
Well, I must say this is not what I expected.
Please see below.
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit 834b22ba762fb59024843a64554d38409aaa82ec
> Author: Paul E. McKenney <[email protected]>
> Date: Tue Jun 4 20:59:35 2024 -0700
>
> tools/memory-model: Add access-marking.txt to README
>
> Given that access-marking.txt exists, this commit makes it easier to find.
>
> Reported-by: Akira Yokosawa <[email protected]>
> Signed-off-by: Paul E. McKenney <[email protected]>
>
> diff --git a/tools/memory-model/Documentation/README b/tools/memory-model/Documentation/README
> index db90a26dbdf40..304162743a5b8 100644
> --- a/tools/memory-model/Documentation/README
> +++ b/tools/memory-model/Documentation/README
> @@ -47,6 +47,10 @@ DESCRIPTION OF FILES
> README
> This file.
>
> +access-marking.txt
> + Guidelines for marking intentionally concurrent accesses to
> + shared memory.
> +
> cheatsheet.txt
> Quick-reference guide to the Linux-kernel memory model.
>
What I expected was an entry in the bullet list in the upper half
of README which mentions access-marking.txt along with the update of
alphabetical list of files.
Updating the latter wouldn't worth bothering you.
And you are missing another comment WRT glossary.txt and locking.txt. ;-)
Let me suggest an idea of their positions in the bullet list where the
ordering is important. Looks reasonable to you ?
o simple.txt
o ordering.txt
o locking.txt <--new
o litmus-test.txt
o recipes.txt
o control-dependencies.txt
o access-marking.txt <--new
o cheatsheet.txt
o explanation.txt
o references.txt
o glossary.txt <--new
Have I made my point clear enough?
Thanks, Akira
On Sat, Jun 08, 2024 at 08:38:12AM +0900, Akira Yokosawa wrote:
> On 2024/06/05 13:02, Paul E. McKenney wrote:
> > On Wed, Jun 05, 2024 at 10:57:27AM +0900, Akira Yokosawa wrote:
> >> On Tue, 4 Jun 2024 15:14:19 -0700, Paul E. McKenney wrote:
> >>> Add a citation to Marco's LF mentorship session presentation entitled
> >>> "The Kernel Concurrency Sanitizer"
> >>>
> >>> [ paulmck: Apply Marco Elver feedback. ]
> >>>
> >>> Reported-by: Marco Elver <[email protected]>
> >>> Signed-off-by: Paul E. McKenney <[email protected]>
> >>> Cc: Alan Stern <[email protected]>
> >>> Cc: Andrea Parri <[email protected]>
> >>> Cc: Will Deacon <[email protected]>
> >>> Cc: Peter Zijlstra <[email protected]>
> >>> Cc: Boqun Feng <[email protected]>
> >>> Cc: Nicholas Piggin <[email protected]>
> >>> Cc: David Howells <[email protected]>
> >>> Cc: Jade Alglave <[email protected]>
> >>> Cc: Luc Maranget <[email protected]>
> >>> Cc: Akira Yokosawa <[email protected]>
> >>
> >> Paul,
> >>
> >> While reviewing this, I noticed that
> >> tools/memory-model/Documentation/README has no mention of
> >> access-marking.txt.
> >>
> >> It has no mention of glossary.txt or locking.txt, either.
> >>
> >> I'm not sure where are the right places in README for them.
> >> Can you update it in a follow-up change?
> >>
> >> Anyway, for this change,
> >>
> >> Reviewed-by: Akira Yokosawa <[email protected]>
> >
> > Thank you, and good catch! Does the patch below look appropriate?
>
> Well, I must say this is not what I expected.
> Please see below.
OK, I was clearly in way too much of a hurry when doing this, and please
accept my apologies for my inattention. I am therefore going to do
what I should have done in the first place, which is to ask you if you
would like to send a patch fixing this. If so, I would be quite happy
to replace mine with yours.
Thanx, Paul
> > ------------------------------------------------------------------------
> >
> > commit 834b22ba762fb59024843a64554d38409aaa82ec
> > Author: Paul E. McKenney <[email protected]>
> > Date: Tue Jun 4 20:59:35 2024 -0700
> >
> > tools/memory-model: Add access-marking.txt to README
> >
> > Given that access-marking.txt exists, this commit makes it easier to find.
> >
> > Reported-by: Akira Yokosawa <[email protected]>
> > Signed-off-by: Paul E. McKenney <[email protected]>
> >
> > diff --git a/tools/memory-model/Documentation/README b/tools/memory-model/Documentation/README
> > index db90a26dbdf40..304162743a5b8 100644
> > --- a/tools/memory-model/Documentation/README
> > +++ b/tools/memory-model/Documentation/README
> > @@ -47,6 +47,10 @@ DESCRIPTION OF FILES
> > README
> > This file.
> >
> > +access-marking.txt
> > + Guidelines for marking intentionally concurrent accesses to
> > + shared memory.
> > +
> > cheatsheet.txt
> > Quick-reference guide to the Linux-kernel memory model.
> >
>
> What I expected was an entry in the bullet list in the upper half
> of README which mentions access-marking.txt along with the update of
> alphabetical list of files.
>
> Updating the latter wouldn't worth bothering you.
>
> And you are missing another comment WRT glossary.txt and locking.txt. ;-)
>
> Let me suggest an idea of their positions in the bullet list where the
> ordering is important. Looks reasonable to you ?
>
> o simple.txt
> o ordering.txt
> o locking.txt <--new
> o litmus-test.txt
> o recipes.txt
> o control-dependencies.txt
> o access-marking.txt <--new
> o cheatsheet.txt
> o explanation.txt
> o references.txt
> o glossary.txt <--new
>
> Have I made my point clear enough?
>
> Thanks, Akira
On 2024/06/09 0:48, Paul E. McKenney wrote:
> On Sat, Jun 08, 2024 at 08:38:12AM +0900, Akira Yokosawa wrote:
>> On 2024/06/05 13:02, Paul E. McKenney wrote:
>>> On Wed, Jun 05, 2024 at 10:57:27AM +0900, Akira Yokosawa wrote:
>>>> On Tue, 4 Jun 2024 15:14:19 -0700, Paul E. McKenney wrote:
>>>>> Add a citation to Marco's LF mentorship session presentation entitled
>>>>> "The Kernel Concurrency Sanitizer"
>>>>>
>>>>> [ paulmck: Apply Marco Elver feedback. ]
>>>>>
>>>>> Reported-by: Marco Elver <[email protected]>
>>>>> Signed-off-by: Paul E. McKenney <[email protected]>
>>>>> Cc: Alan Stern <[email protected]>
>>>>> Cc: Andrea Parri <[email protected]>
>>>>> Cc: Will Deacon <[email protected]>
>>>>> Cc: Peter Zijlstra <[email protected]>
>>>>> Cc: Boqun Feng <[email protected]>
>>>>> Cc: Nicholas Piggin <[email protected]>
>>>>> Cc: David Howells <[email protected]>
>>>>> Cc: Jade Alglave <[email protected]>
>>>>> Cc: Luc Maranget <[email protected]>
>>>>> Cc: Akira Yokosawa <[email protected]>
>>>>
>>>> Paul,
>>>>
>>>> While reviewing this, I noticed that
>>>> tools/memory-model/Documentation/README has no mention of
>>>> access-marking.txt.
>>>>
>>>> It has no mention of glossary.txt or locking.txt, either.
>>>>
>>>> I'm not sure where are the right places in README for them.
>>>> Can you update it in a follow-up change?
>>>>
>>>> Anyway, for this change,
>>>>
>>>> Reviewed-by: Akira Yokosawa <[email protected]>
>>>
>>> Thank you, and good catch! Does the patch below look appropriate?
>>
>> Well, I must say this is not what I expected.
>> Please see below.
>
> OK, I was clearly in way too much of a hurry when doing this, and please
> accept my apologies for my inattention. I am therefore going to do
> what I should have done in the first place, which is to ask you if you
> would like to send a patch fixing this. If so, I would be quite happy
> to replace mine with yours.
OK.
I think I can submit a draft patch after fixing perfbook's build error
caused by changes in core LaTeX packages released last week.
Can you wait for a while ?
Thanks, Akira
On Sun, Jun 09, 2024 at 09:04:14AM +0900, Akira Yokosawa wrote:
> On 2024/06/09 0:48, Paul E. McKenney wrote:
> > On Sat, Jun 08, 2024 at 08:38:12AM +0900, Akira Yokosawa wrote:
> >> On 2024/06/05 13:02, Paul E. McKenney wrote:
> >>> On Wed, Jun 05, 2024 at 10:57:27AM +0900, Akira Yokosawa wrote:
> >>>> On Tue, 4 Jun 2024 15:14:19 -0700, Paul E. McKenney wrote:
> >>>>> Add a citation to Marco's LF mentorship session presentation entitled
> >>>>> "The Kernel Concurrency Sanitizer"
> >>>>>
> >>>>> [ paulmck: Apply Marco Elver feedback. ]
> >>>>>
> >>>>> Reported-by: Marco Elver <[email protected]>
> >>>>> Signed-off-by: Paul E. McKenney <[email protected]>
> >>>>> Cc: Alan Stern <[email protected]>
> >>>>> Cc: Andrea Parri <[email protected]>
> >>>>> Cc: Will Deacon <[email protected]>
> >>>>> Cc: Peter Zijlstra <[email protected]>
> >>>>> Cc: Boqun Feng <[email protected]>
> >>>>> Cc: Nicholas Piggin <[email protected]>
> >>>>> Cc: David Howells <[email protected]>
> >>>>> Cc: Jade Alglave <[email protected]>
> >>>>> Cc: Luc Maranget <[email protected]>
> >>>>> Cc: Akira Yokosawa <[email protected]>
> >>>>
> >>>> Paul,
> >>>>
> >>>> While reviewing this, I noticed that
> >>>> tools/memory-model/Documentation/README has no mention of
> >>>> access-marking.txt.
> >>>>
> >>>> It has no mention of glossary.txt or locking.txt, either.
> >>>>
> >>>> I'm not sure where are the right places in README for them.
> >>>> Can you update it in a follow-up change?
> >>>>
> >>>> Anyway, for this change,
> >>>>
> >>>> Reviewed-by: Akira Yokosawa <[email protected]>
> >>>
> >>> Thank you, and good catch! Does the patch below look appropriate?
> >>
> >> Well, I must say this is not what I expected.
> >> Please see below.
> >
> > OK, I was clearly in way too much of a hurry when doing this, and please
> > accept my apologies for my inattention. I am therefore going to do
> > what I should have done in the first place, which is to ask you if you
> > would like to send a patch fixing this. If so, I would be quite happy
> > to replace mine with yours.
>
> OK.
> I think I can submit a draft patch after fixing perfbook's build error
> caused by changes in core LaTeX packages released last week.
Ouch! Thank you for keeping up with this!
> Can you wait for a while ?
No hurry here. It has been this way for some years, so a little while
longer is not a disaster.
Thanx, Paul