[PATCH memory-model 0/3] LKMM updates for v6.11

[PATCH memory-model 0/3] LKMM updates for v6.11

[Paul E. McKenney]

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(-)

[PATCH memory-model 1/3] tools/memory-model: Add atomic_and()/or()/xor() and add_negative

[Paul E. McKenney]

From: Puranjay Mohan <puranjay@kernel.org>

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 <puranjay@kernel.org>
Acked-by: Andrea Parri <parri.andrea@gmail.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Will Deacon <will@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jade Alglave <j.alglave@ucl.ac.uk>
Cc: Luc Maranget <luc.maranget@inria.fr>
Cc: Akira Yokosawa <akiyks@gmail.com>
Cc: Daniel Lustig <dlustig@nvidia.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: <linux-arch@vger.kernel.org>
---
 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

Re: [PATCH memory-model 1/3] tools/memory-model: Add atomic_and()/or()/xor() and add_negative

[Akira Yokosawa]

Hi,

On Tue,  4 Jun 2024 15:14:17 -0700, Paul E. McKenney wrote:
> From: Puranjay Mohan <puranjay@kernel.org>
> 
> 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 <puranjay@kernel.org>
> Acked-by: Andrea Parri <parri.andrea@gmail.com>
> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Will Deacon <will@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> Cc: Luc Maranget <luc.maranget@inria.fr>
> Cc: Akira Yokosawa <akiyks@gmail.com>

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 <dlustig@nvidia.com>
> Cc: Joel Fernandes <joel@joelfernandes.org>
> Cc: <linux-arch@vger.kernel.org>

Re: [PATCH memory-model 1/3] tools/memory-model: Add atomic_and()/or()/xor() and add_negative

[Paul E. McKenney]

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 <puranjay@kernel.org>
> > 
> > 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 <puranjay@kernel.org>
> > Acked-by: Andrea Parri <parri.andrea@gmail.com>
> > Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Nicholas Piggin <npiggin@gmail.com>
> > Cc: David Howells <dhowells@redhat.com>
> > Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> > Cc: Luc Maranget <luc.maranget@inria.fr>
> > Cc: Akira Yokosawa <akiyks@gmail.com>
> 
> 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

[PATCH memory-model 2/3] tools/memory-model: Add atomic_andnot() with its variants

[Paul E. McKenney]

From: Puranjay Mohan <puranjay@kernel.org>

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 <puranjay@kernel.org>
Acked-by: Andrea Parri <parri.andrea@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Will Deacon <will@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jade Alglave <j.alglave@ucl.ac.uk>
Cc: Luc Maranget <luc.maranget@inria.fr>
Cc: Akira Yokosawa <akiyks@gmail.com>
Cc: Daniel Lustig <dlustig@nvidia.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: <linux-arch@vger.kernel.org>
---
 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

[PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Paul E. McKenney]

Add a citation to Marco's LF mentorship session presentation entitled
"The Kernel Concurrency Sanitizer"

[ paulmck: Apply Marco Elver feedback. ]

Reported-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrea Parri <parri.andrea@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jade Alglave <j.alglave@ucl.ac.uk>
Cc: Luc Maranget <luc.maranget@inria.fr>
Cc: Akira Yokosawa <akiyks@gmail.com>
Cc: Daniel Lustig <dlustig@nvidia.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: <linux-arch@vger.kernel.org>
---
 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

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Andrea Parri]

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 <elver@google.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Acked-by: Andrea Parri <parri.andrea@gmail.com>

  Andrea

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Paul E. McKenney]

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 <elver@google.com>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Acked-by: Andrea Parri <parri.andrea@gmail.com>

Thank you!  I will apply this along with Akira's on my next rebase.

							Thanx, Paul

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Akira Yokosawa]

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 <elver@google.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Andrea Parri <parri.andrea@gmail.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> Cc: Luc Maranget <luc.maranget@inria.fr>
> Cc: Akira Yokosawa <akiyks@gmail.com>

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 <akiyks@gmail.com>

        Thanks, Akira

> Cc: Daniel Lustig <dlustig@nvidia.com>
> Cc: Joel Fernandes <joel@joelfernandes.org>
> Cc: <linux-arch@vger.kernel.org>
> ---

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Paul E. McKenney]

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 <elver@google.com>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: Andrea Parri <parri.andrea@gmail.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Boqun Feng <boqun.feng@gmail.com>
> > Cc: Nicholas Piggin <npiggin@gmail.com>
> > Cc: David Howells <dhowells@redhat.com>
> > Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> > Cc: Luc Maranget <luc.maranget@inria.fr>
> > Cc: Akira Yokosawa <akiyks@gmail.com>
> 
> 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 <akiyks@gmail.com>

Thank you, and good catch!  Does the patch below look appropriate?

							Thanx, Paul

------------------------------------------------------------------------

commit 834b22ba762fb59024843a64554d38409aaa82ec
Author: Paul E. McKenney <paulmck@kernel.org>
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 <akiyks@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

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.
 

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Akira Yokosawa]

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 <elver@google.com>
>>> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>>> Cc: Alan Stern <stern@rowland.harvard.edu>
>>> Cc: Andrea Parri <parri.andrea@gmail.com>
>>> Cc: Will Deacon <will@kernel.org>
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> Cc: Boqun Feng <boqun.feng@gmail.com>
>>> Cc: Nicholas Piggin <npiggin@gmail.com>
>>> Cc: David Howells <dhowells@redhat.com>
>>> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
>>> Cc: Luc Maranget <luc.maranget@inria.fr>
>>> Cc: Akira Yokosawa <akiyks@gmail.com>
>>
>> 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 <akiyks@gmail.com>
> 
> 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 <paulmck@kernel.org>
> 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 <akiyks@gmail.com>
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> 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

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Paul E. McKenney]

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 <elver@google.com>
> >>> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> >>> Cc: Alan Stern <stern@rowland.harvard.edu>
> >>> Cc: Andrea Parri <parri.andrea@gmail.com>
> >>> Cc: Will Deacon <will@kernel.org>
> >>> Cc: Peter Zijlstra <peterz@infradead.org>
> >>> Cc: Boqun Feng <boqun.feng@gmail.com>
> >>> Cc: Nicholas Piggin <npiggin@gmail.com>
> >>> Cc: David Howells <dhowells@redhat.com>
> >>> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> >>> Cc: Luc Maranget <luc.maranget@inria.fr>
> >>> Cc: Akira Yokosawa <akiyks@gmail.com>
> >>
> >> 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 <akiyks@gmail.com>
> > 
> > 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 <paulmck@kernel.org>
> > 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 <akiyks@gmail.com>
> >     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > 
> > 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

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Akira Yokosawa]

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 <elver@google.com>
>>>>> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>>>>> Cc: Alan Stern <stern@rowland.harvard.edu>
>>>>> Cc: Andrea Parri <parri.andrea@gmail.com>
>>>>> Cc: Will Deacon <will@kernel.org>
>>>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>>>> Cc: Boqun Feng <boqun.feng@gmail.com>
>>>>> Cc: Nicholas Piggin <npiggin@gmail.com>
>>>>> Cc: David Howells <dhowells@redhat.com>
>>>>> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
>>>>> Cc: Luc Maranget <luc.maranget@inria.fr>
>>>>> Cc: Akira Yokosawa <akiyks@gmail.com>
>>>>
>>>> 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 <akiyks@gmail.com>
>>>
>>> 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

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Paul E. McKenney]

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 <elver@google.com>
> >>>>> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> >>>>> Cc: Alan Stern <stern@rowland.harvard.edu>
> >>>>> Cc: Andrea Parri <parri.andrea@gmail.com>
> >>>>> Cc: Will Deacon <will@kernel.org>
> >>>>> Cc: Peter Zijlstra <peterz@infradead.org>
> >>>>> Cc: Boqun Feng <boqun.feng@gmail.com>
> >>>>> Cc: Nicholas Piggin <npiggin@gmail.com>
> >>>>> Cc: David Howells <dhowells@redhat.com>
> >>>>> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> >>>>> Cc: Luc Maranget <luc.maranget@inria.fr>
> >>>>> Cc: Akira Yokosawa <akiyks@gmail.com>
> >>>>
> >>>> 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 <akiyks@gmail.com>
> >>>
> >>> 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

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Marco Elver]

On Wed, 5 Jun 2024 at 00:14, Paul E. McKenney <paulmck@kernel.org> 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 <elver@google.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Acked-by: Marco Elver <elver@google.com>

Thanks for adding.

> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Andrea Parri <parri.andrea@gmail.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> Cc: Luc Maranget <luc.maranget@inria.fr>
> Cc: Akira Yokosawa <akiyks@gmail.com>
> Cc: Daniel Lustig <dlustig@nvidia.com>
> Cc: Joel Fernandes <joel@joelfernandes.org>
> Cc: <linux-arch@vger.kernel.org>
> ---
>  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
>

Re: [PATCH memory-model 3/3] tools/memory-model: Add KCSAN LF mentorship session citation

[Paul E. McKenney]

On Wed, Jun 05, 2024 at 09:52:38AM +0200, Marco Elver wrote:
> On Wed, 5 Jun 2024 at 00:14, Paul E. McKenney <paulmck@kernel.org> 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 <elver@google.com>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Acked-by: Marco Elver <elver@google.com>
> 
> Thanks for adding.

I will apply your ack on my next rebase, thank you!

							Thanx, Paul

> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: Andrea Parri <parri.andrea@gmail.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Boqun Feng <boqun.feng@gmail.com>
> > Cc: Nicholas Piggin <npiggin@gmail.com>
> > Cc: David Howells <dhowells@redhat.com>
> > Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> > Cc: Luc Maranget <luc.maranget@inria.fr>
> > Cc: Akira Yokosawa <akiyks@gmail.com>
> > Cc: Daniel Lustig <dlustig@nvidia.com>
> > Cc: Joel Fernandes <joel@joelfernandes.org>
> > Cc: <linux-arch@vger.kernel.org>
> > ---
> >  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
> >