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.1On 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 >
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 > >
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>
> ---
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.
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.