| Message ID | 20180628123347.52963-1-mark.rutland@arm.com |
|---|---|
| Headers | show |
| Series | tools/memory-model: remove ACCESS_ONCE() | expand |
On Thu, Jun 28, 2018 at 01:33:45PM +0100, Mark Rutland wrote: > Since commit: > > b899a850431e2dd0 ("compiler.h: Remove ACCESS_ONCE()") > > ... there has been no definition of ACCESS_ONCE() in the kernel tree, > and it has been necessary to use READ_ONCE() or WRITE_ONCE() instead. > > However, since then the kernel memory model was added to the Linux tree, > sporting new instances of ACCESS_ONCE() in examples and in the memory > model itself. > > These patches remove the new instances of ACCESS_ONCE() for consistency > with the contemporary codebase. > > Thanks, > Mark. > > Mark Rutland (2): > tools/memory-model: remove ACCESS_ONCE() from recipes > tools/memory-model: remove ACCESS_ONCE() from model For the series: Acked-by: Andrea Parri <andrea.parri@amarulasolutions.com> Cheers, Andrea > > tools/memory-model/Documentation/recipes.txt | 4 ++-- > tools/memory-model/linux-kernel.bell | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > -- > 2.11.0 >
On Thu, Jun 28, 2018 at 02:38:45PM +0200, Andrea Parri wrote: > On Thu, Jun 28, 2018 at 01:33:45PM +0100, Mark Rutland wrote: > > Since commit: > > > > b899a850431e2dd0 ("compiler.h: Remove ACCESS_ONCE()") > > > > ... there has been no definition of ACCESS_ONCE() in the kernel tree, > > and it has been necessary to use READ_ONCE() or WRITE_ONCE() instead. > > > > However, since then the kernel memory model was added to the Linux tree, > > sporting new instances of ACCESS_ONCE() in examples and in the memory > > model itself. > > > > These patches remove the new instances of ACCESS_ONCE() for consistency > > with the contemporary codebase. > > > > Thanks, > > Mark. > > > > Mark Rutland (2): > > tools/memory-model: remove ACCESS_ONCE() from recipes > > tools/memory-model: remove ACCESS_ONCE() from model > > For the series: > > Acked-by: Andrea Parri <andrea.parri@amarulasolutions.com> Applied, thank you both! These both are ready for the upcoming merge window. While I am at it, here is the current scorecard: e9ff68680cd4 tools/memory-model: Add litmus test for full multicopy atomicity c21fcc6594f1 tools/memory-model: Fix ISA2+pooncelock+pooncelock+pombonce name aa838e0b70e1 MAINTAINERS: Add Daniel Lustig as an LKMM reviewer 3cb0d7701c4c locking/memory-barriers.txt/kokr: Update Korean translation to fix broken DMA vs. MMIO ordering example 0bde941f3629 tools/memory-model: Remove ACCESS_ONCE() from recipes 80b7b05c3aa0 tools/memory-model: Remove ACCESS_ONCE() from model The above patches are ready for the upcoming merge window because each has at least one Acked-by or Reviewed-by. 6098ce88bc4d tools/memory-model: Make scripts executable 5bb22d0126f9 tools/memory-model: Rename litmus tests to comply to norm7 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation The above patches need at least one additional Acked-by or Reviewed-by. If any of you gets a chance, please do look them over. 51b0a8985c5a EXP tools/memory-model: Add litmus-test naming scheme This patch needs me to get Will Deacon's feedback applied. :-/ 06e99a0d9662 EXP tools/memory-model: Add .cfg and .cat files for s390 This is a placeholder, and probably won't ever go upstream into the Linux kernel. (Maybe someday into herd where the other architecture-specific .cat files live.) Thanx, Paul > Cheers, > Andrea > > > > > > tools/memory-model/Documentation/recipes.txt | 4 ++-- > > tools/memory-model/linux-kernel.bell | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > -- > > 2.11.0 > > >
> 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation > > The above patches need at least one additional Acked-by > or Reviewed-by. If any of you gets a chance, please do > look them over. Glad this came out. ;-) No objection to the patch: feel free to add my Reviewed-by: tag. (BTW, atomic_set() would be better mapped to WRITE_ONCE()... in fact, to be fair, some archs do it the __asm__ __volatile__() way). I do however have some suggestions concerning "the process": searching LKML for the patch and the related discussion, I could only find: [PATCH] docs: atomic_ops: atomic_set is a write (not read) operation and I realize that none of the person Cc:-ed in this thread, except you, were Cc:-ed in that discussion (in compliance with get_maintainer.pl). My suggestions: 1) Merge the file touched by that patch into (the recently created): Documentation/atomic_t.txt (FWIW, queued in my TODO list). 2) Add the entry: F: Documentation/atomic_t.txt to the "ATOMIC INFRASTRUCTURE" subsystem in the MAINTAINERS file so that developers can easily find (the intended?) reviewers for their patch. (Of course, this will need ACK from the ATOMIC people). Andrea
On 2018/06/28 08:21:40 -0700, Paul E. McKenney wrote: [...] > > While I am at it, here is the current scorecard: > > e9ff68680cd4 tools/memory-model: Add litmus test for full multicopy atomicity > c21fcc6594f1 tools/memory-model: Fix ISA2+pooncelock+pooncelock+pombonce name > aa838e0b70e1 MAINTAINERS: Add Daniel Lustig as an LKMM reviewer > 3cb0d7701c4c locking/memory-barriers.txt/kokr: Update Korean translation to fix broken DMA vs. MMIO ordering example > 0bde941f3629 tools/memory-model: Remove ACCESS_ONCE() from recipes > 80b7b05c3aa0 tools/memory-model: Remove ACCESS_ONCE() from model > > The above patches are ready for the upcoming merge window because > each has at least one Acked-by or Reviewed-by. > > 6098ce88bc4d tools/memory-model: Make scripts executable In this commit, "Usage:" in the header of scripts/checklitmus.sh should also be updated. When it is fixed, Acked-by: Akira Yokosawa <akiyks@gmail.com> Thanks, Akira > 5bb22d0126f9 tools/memory-model: Rename litmus tests to comply to norm7 > 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation > > The above patches need at least one additional Acked-by > or Reviewed-by. If any of you gets a chance, please do > look them over. > > 51b0a8985c5a EXP tools/memory-model: Add litmus-test naming scheme > > This patch needs me to get Will Deacon's feedback applied. :-/ > > 06e99a0d9662 EXP tools/memory-model: Add .cfg and .cat files for s390 > > This is a placeholder, and probably won't ever go upstream > into the Linux kernel. (Maybe someday into herd where the > other architecture-specific .cat files live.) > > Thanx, Paul > >> Cheers, >> Andrea >> >> >>> >>> tools/memory-model/Documentation/recipes.txt | 4 ++-- >>> tools/memory-model/linux-kernel.bell | 2 +- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >>> >>> -- >>> 2.11.0 >>> >> >
On Fri, Jun 29, 2018 at 07:22:22AM +0900, Akira Yokosawa wrote: > On 2018/06/28 08:21:40 -0700, Paul E. McKenney wrote: > [...] > > > > While I am at it, here is the current scorecard: > > > > e9ff68680cd4 tools/memory-model: Add litmus test for full multicopy atomicity > > c21fcc6594f1 tools/memory-model: Fix ISA2+pooncelock+pooncelock+pombonce name > > aa838e0b70e1 MAINTAINERS: Add Daniel Lustig as an LKMM reviewer > > 3cb0d7701c4c locking/memory-barriers.txt/kokr: Update Korean translation to fix broken DMA vs. MMIO ordering example > > 0bde941f3629 tools/memory-model: Remove ACCESS_ONCE() from recipes > > 80b7b05c3aa0 tools/memory-model: Remove ACCESS_ONCE() from model > > > > The above patches are ready for the upcoming merge window because > > each has at least one Acked-by or Reviewed-by. > > > > 6098ce88bc4d tools/memory-model: Make scripts executable > > In this commit, "Usage:" in the header of scripts/checklitmus.sh should > also be updated. > > When it is fixed, > > Acked-by: Akira Yokosawa <akiyks@gmail.com> Done, applied, and thank you! Thanx, Paul > Thanks, Akira > > > 5bb22d0126f9 tools/memory-model: Rename litmus tests to comply to norm7 > > 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation > > > > The above patches need at least one additional Acked-by > > or Reviewed-by. If any of you gets a chance, please do > > look them over. > > > > 51b0a8985c5a EXP tools/memory-model: Add litmus-test naming scheme > > > > This patch needs me to get Will Deacon's feedback applied. :-/ > > > > 06e99a0d9662 EXP tools/memory-model: Add .cfg and .cat files for s390 > > > > This is a placeholder, and probably won't ever go upstream > > into the Linux kernel. (Maybe someday into herd where the > > other architecture-specific .cat files live.) > > > > Thanx, Paul > > > >> Cheers, > >> Andrea > >> > >> > >>> > >>> tools/memory-model/Documentation/recipes.txt | 4 ++-- > >>> tools/memory-model/linux-kernel.bell | 2 +- > >>> 2 files changed, 3 insertions(+), 3 deletions(-) > >>> > >>> -- > >>> 2.11.0 > >>> > >> > > >
On Thu, Jun 28, 2018 at 06:51:11PM +0200, Andrea Parri wrote: > > 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation > > > > The above patches need at least one additional Acked-by > > or Reviewed-by. If any of you gets a chance, please do > > look them over. > > Glad this came out. ;-) > > No objection to the patch: feel free to add my Reviewed-by: tag. Done, thank you! > (BTW, atomic_set() would be better mapped to WRITE_ONCE()... in fact, to > be fair, some archs do it the __asm__ __volatile__() way). > > I do however have some suggestions concerning "the process": searching > LKML for the patch and the related discussion, I could only find: > > [PATCH] docs: atomic_ops: atomic_set is a write (not read) operation > > and I realize that none of the person Cc:-ed in this thread, except you, > were Cc:-ed in that discussion (in compliance with get_maintainer.pl). > > My suggestions: > > 1) Merge the file touched by that patch into (the recently created): > > Documentation/atomic_t.txt > > (FWIW, queued in my TODO list). Some consolidation of documentation would be good. ;-) Thoughts from others? > 2) Add the entry: > > F: Documentation/atomic_t.txt > > to the "ATOMIC INFRASTRUCTURE" subsystem in the MAINTAINERS file so > that developers can easily find (the intended?) reviewers for their > patch. (Of course, this will need ACK from the ATOMIC people). If the merging will take awhile, it might also be good to put Documentation/core-api/atomic_ops.rst somewhere as well. Thanx, Paul
> > 1) Merge the file touched by that patch into (the recently created): > > > > Documentation/atomic_t.txt > > > > (FWIW, queued in my TODO list). > > Some consolidation of documentation would be good. ;-) > > Thoughts from others? > > > 2) Add the entry: > > > > F: Documentation/atomic_t.txt > > > > to the "ATOMIC INFRASTRUCTURE" subsystem in the MAINTAINERS file so > > that developers can easily find (the intended?) reviewers for their > > patch. (Of course, this will need ACK from the ATOMIC people). > > If the merging will take awhile, it might also be good to put > Documentation/core-api/atomic_ops.rst somewhere as well. Indeed. And let's not forget the "orphaned": Documentation/atomic_bitops.txt Documentation/core-api/refcount-vs-atomic.rst ;-) Andrea
On Tue, Jul 03, 2018 at 12:12:41PM +0200, Andrea Parri wrote: > > > 1) Merge the file touched by that patch into (the recently created): > > > > > > Documentation/atomic_t.txt > > > > > > (FWIW, queued in my TODO list). > > > > Some consolidation of documentation would be good. ;-) > > > > Thoughts from others? > > > > > 2) Add the entry: > > > > > > F: Documentation/atomic_t.txt > > > > > > to the "ATOMIC INFRASTRUCTURE" subsystem in the MAINTAINERS file so > > > that developers can easily find (the intended?) reviewers for their > > > patch. (Of course, this will need ACK from the ATOMIC people). > > > > If the merging will take awhile, it might also be good to put > > Documentation/core-api/atomic_ops.rst somewhere as well. > > Indeed. And let's not forget the "orphaned": > > Documentation/atomic_bitops.txt > Documentation/core-api/refcount-vs-atomic.rst Lots of puppies to adopt, aren't there? ;-) I could make the argument that these files are part of the documentation for the Linux kernel's memory model, and that they should therefore be added to the LKMM MAINTAINERS entry. Any objections? (Adding David Miller in his capacity of author of atomic_ops.txt.) Separately, it might be good to make sure that the linux-arch folks are aware of proposed changes to the memory model. To that end, would it make sense to add the linux-arch mailing list to that same entry? Thanx, Paul ------------------------------------------------------------------------ commit 33a58ee5eadadfb1f4850eabd4fac332984881d5 Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Date: Tue Jul 3 08:48:09 2018 -0700 tools/memory-model: Add informal LKMM documentation to MAINTAINERS The Linux-kernel memory model has been informal, with a number of text files documenting it. It would be good to make sure that these informal descriptions are kept up to date and/or pruned appropriately. This commit therefore brings more of those text files into the LKMM MAINTAINERS file entry. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andrea Parri <andrea.parri@amarulasolutions.com> Cc: Will Deacon <will.deacon@arm.com> 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: "David S. Miller" <davem@davemloft.net> diff --git a/MAINTAINERS b/MAINTAINERS index f2903b818671..2ba947fc9a2f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8321,6 +8321,10 @@ L: linux-kernel@vger.kernel.org S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git F: tools/memory-model/ +F: Documentation/atomic_bitops.txt +F: Documentation/atomic_t.txt +F: Documentation/core-api/atomic_ops.rst +F: Documentation/core-api/refcount-vs-atomic.rst F: Documentation/memory-barriers.txt LINUX SECURITY MODULE (LSM) FRAMEWORK
> commit 33a58ee5eadadfb1f4850eabd4fac332984881d5 > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Date: Tue Jul 3 08:48:09 2018 -0700 > > tools/memory-model: Add informal LKMM documentation to MAINTAINERS > > The Linux-kernel memory model has been informal, with a number of > text files documenting it. It would be good to make sure that these > informal descriptions are kept up to date and/or pruned appropriately. > This commit therefore brings more of those text files into the LKMM > MAINTAINERS file entry. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Cc: Alan Stern <stern@rowland.harvard.edu> > Cc: Andrea Parri <andrea.parri@amarulasolutions.com> > Cc: Will Deacon <will.deacon@arm.com> > 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: "David S. Miller" <davem@davemloft.net> With the disclaimer that I'm not (yet) familiar with reST, Acked-by: Andrea Parri <andrea.parri@amarulasolutions.com> Adding the linux-arch ML, as you suggested, would also make sense to me. Thanks, Andrea > > diff --git a/MAINTAINERS b/MAINTAINERS > index f2903b818671..2ba947fc9a2f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8321,6 +8321,10 @@ L: linux-kernel@vger.kernel.org > S: Supported > T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > F: tools/memory-model/ > +F: Documentation/atomic_bitops.txt > +F: Documentation/atomic_t.txt > +F: Documentation/core-api/atomic_ops.rst > +F: Documentation/core-api/refcount-vs-atomic.rst > F: Documentation/memory-barriers.txt > > LINUX SECURITY MODULE (LSM) FRAMEWORK >
On Tue, Jul 03, 2018 at 07:23:42PM +0200, Andrea Parri wrote: > > commit 33a58ee5eadadfb1f4850eabd4fac332984881d5 > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Date: Tue Jul 3 08:48:09 2018 -0700 > > > > tools/memory-model: Add informal LKMM documentation to MAINTAINERS > > > > The Linux-kernel memory model has been informal, with a number of > > text files documenting it. It would be good to make sure that these > > informal descriptions are kept up to date and/or pruned appropriately. > > This commit therefore brings more of those text files into the LKMM > > MAINTAINERS file entry. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Cc: Alan Stern <stern@rowland.harvard.edu> > > Cc: Andrea Parri <andrea.parri@amarulasolutions.com> > > Cc: Will Deacon <will.deacon@arm.com> > > 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: "David S. Miller" <davem@davemloft.net> > > With the disclaimer that I'm not (yet) familiar with reST, > > Acked-by: Andrea Parri <andrea.parri@amarulasolutions.com> > > Adding the linux-arch ML, as you suggested, would also make sense to me. Very good, thank you! I have a --squash commit in -rcu to add your ack and also linux-arch@vger.kernel.org. Thanx, Paul > Thanks, > Andrea > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index f2903b818671..2ba947fc9a2f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -8321,6 +8321,10 @@ L: linux-kernel@vger.kernel.org > > S: Supported > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > > F: tools/memory-model/ > > +F: Documentation/atomic_bitops.txt > > +F: Documentation/atomic_t.txt > > +F: Documentation/core-api/atomic_ops.rst > > +F: Documentation/core-api/refcount-vs-atomic.rst > > F: Documentation/memory-barriers.txt > > > > LINUX SECURITY MODULE (LSM) FRAMEWORK > > >
Since commit: b899a850431e2dd0 ("compiler.h: Remove ACCESS_ONCE()") ... there has been no definition of ACCESS_ONCE() in the kernel tree, and it has been necessary to use READ_ONCE() or WRITE_ONCE() instead. However, since then the kernel memory model was added to the Linux tree, sporting new instances of ACCESS_ONCE() in examples and in the memory model itself. These patches remove the new instances of ACCESS_ONCE() for consistency with the contemporary codebase. Thanks, Mark. Mark Rutland (2): tools/memory-model: remove ACCESS_ONCE() from recipes tools/memory-model: remove ACCESS_ONCE() from model tools/memory-model/Documentation/recipes.txt | 4 ++-- tools/memory-model/linux-kernel.bell | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.11.0