Re: [PATCH kcsan 8/9] tools/memory-model: Document categories of ordering primitives

Paul E. McKenney
2020-09-01T02:58:57Z

On Mon, Aug 31, 2020 at 09:23:09PM -0400, Alan Stern wrote:
> On Mon, Aug 31, 2020 at 11:20:36AM -0700, paulmck@kernel.org wrote:
> > From: "Paul E. McKenney" <paulmck@kernel.org>
> >
> > The Linux kernel has a number of categories of ordering primitives, which
> > are recorded in the LKMM implementation and hinted at by cheatsheet.txt.
> > But there is no overview of these categories, and such an overview
> > is needed in order to understand multithreaded LKMM litmus tests.
> > This commit therefore adds an ordering.txt as well as extracting a
> > control-dependencies.txt from memory-barriers.txt. It also updates the
> > README file.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > ---
>
> This document could use some careful editing. But one pair of errors
> stands out in particular:
>
> > diff --git a/tools/memory-model/Documentation/ordering.txt b/tools/memory-model/Documentation/ordering.txt
> > new file mode 100644
> > index 0000000..4b2cc55
> > --- /dev/null
> > +++ b/tools/memory-model/Documentation/ordering.txt
>
> > +2. Ordered memory accesses. These operations order themselves
> > + against some or all of the CPUs prior or subsequent accesses,
> > + depending on the category of operation.
> > +
> > + a. Release operations. This category includes
> > + smp_store_release(), atomic_set_release(),
> > + rcu_assign_pointer(), and value-returning RMW operations
> > + whose names end in _release. These operations order
> > + their own store against all of the CPU's subsequent
> ---------------------------------------------------------^^^^^^^^^^
> > + memory accesses.
> > +
> > + b. Acquire operations. This category includes
> > + smp_load_acquire(), atomic_read_acquire(), and
> > + value-returning RMW operations whose names end in
> > + _acquire. These operations order their own load against
> > + all of the CPU's prior memory accesses.
> ---------------------------------^^^^^
>
> Double-oops!

Hey, at least I am consistently wrong! ;-)

Fixed, thank you!

Thanx, Paul