From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Boqun Feng <boqun.feng@gmail.com>,
Daniel Lustig <dlustig@nvidia.com>,
David Howells <dhowells@redhat.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>,
Nicholas Piggin <npiggin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
Date: Tue, 10 Jul 2018 12:58:53 -0700 [thread overview]
Message-ID: <20180710195853.GC3593@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1807101416390.1449-100000@iolanthe.rowland.org>
On Tue, Jul 10, 2018 at 02:18:13PM -0400, Alan Stern wrote:
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by locking. In other words, given
> the following code:
>
> WRITE_ONCE(x, 1);
> spin_unlock(&s):
> spin_lock(&s);
> WRITE_ONCE(y, 1);
>
> the stores to x and y should be propagated in order to all other CPUs,
> even though those other CPUs might not access the lock s. In terms of
> the memory model, this means expanding the cumul-fence relation.
>
> Locks should also provide read-read (and read-write) ordering in a
> similar way. Given:
>
> READ_ONCE(x);
> spin_unlock(&s);
> spin_lock(&s);
> READ_ONCE(y); // or WRITE_ONCE(y, 1);
>
> the load of x should be executed before the load of (or store to) y.
> The LKMM already provides this ordering, but it provides it even in
> the case where the two accesses are separated by a release/acquire
> pair of fences rather than unlock/lock. This would prevent
> architectures from using weakly ordered implementations of release and
> acquire, which seems like an unnecessary restriction. The patch
> therefore removes the ordering requirement from the LKMM for that
> case.
>
> All the architectures supported by the Linux kernel (including RISC-V)
> do provide this ordering for locks, albeit for varying reasons.
> Therefore this patch changes the model in accordance with the
> developers' wishes.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
It now applies, thank you very much!
Is this something that you are comfortable pushing into the upcoming
merge window, or should I hold off until the next one?
Thanx, Paul
> ---
>
>
> v.3: Rebased against the dev branch of Paul's linux-rcu tree.
> Changed unlock-rf-lock-po to po-unlock-rf-lock-po, making it more
> symmetrical and more in accordance with the use of fence.tso for
> the release on RISC-V.
>
> v.2: Restrict the ordering to lock operations, not general release
> and acquire fences.
>
> [as1871c]
>
>
> tools/memory-model/Documentation/explanation.txt | 186 +++++++---
> tools/memory-model/linux-kernel.cat | 8
> tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus | 7
> 3 files changed, 150 insertions(+), 51 deletions(-)
>
> Index: usb-4.x/tools/memory-model/linux-kernel.cat
> ===================================================================
> --- usb-4.x.orig/tools/memory-model/linux-kernel.cat
> +++ usb-4.x/tools/memory-model/linux-kernel.cat
> @@ -38,7 +38,7 @@ let strong-fence = mb | gp
> (* Release Acquire *)
> let acq-po = [Acquire] ; po ; [M]
> let po-rel = [M] ; po ; [Release]
> -let rfi-rel-acq = [Release] ; rfi ; [Acquire]
> +let po-unlock-rf-lock-po = po ; [UL] ; rf ; [LKR] ; po
>
> (**********************************)
> (* Fundamental coherence ordering *)
> @@ -60,13 +60,13 @@ let dep = addr | data
> let rwdep = (dep | ctrl) ; [W]
> let overwrite = co | fr
> let to-w = rwdep | (overwrite & int)
> -let to-r = addr | (dep ; rfi) | rfi-rel-acq
> +let to-r = addr | (dep ; rfi)
> let fence = strong-fence | wmb | po-rel | rmb | acq-po
> -let ppo = to-r | to-w | fence
> +let ppo = to-r | to-w | fence | (po-unlock-rf-lock-po & int)
>
> (* Propagation: Ordering from release operations and strong fences. *)
> let A-cumul(r) = rfe? ; r
> -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb
> +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | po-unlock-rf-lock-po
> let prop = (overwrite & ext)? ; cumul-fence* ; rfe?
>
> (*
> Index: usb-4.x/tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus
> ===================================================================
> --- usb-4.x.orig/tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus
> +++ usb-4.x/tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus
> @@ -1,11 +1,10 @@
> C ISA2+pooncelock+pooncelock+pombonce
>
> (*
> - * Result: Sometimes
> + * Result: Never
> *
> - * This test shows that the ordering provided by a lock-protected S
> - * litmus test (P0() and P1()) are not visible to external process P2().
> - * This is likely to change soon.
> + * This test shows that write-write ordering provided by locks
> + * (in P0() and P1()) is visible to external process P2().
> *)
>
> {}
> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt
> ===================================================================
> --- usb-4.x.orig/tools/memory-model/Documentation/explanation.txt
> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt
> @@ -28,7 +28,8 @@ Explanation of the Linux-Kernel Memory C
> 20. THE HAPPENS-BEFORE RELATION: hb
> 21. THE PROPAGATES-BEFORE RELATION: pb
> 22. RCU RELATIONS: rcu-link, gp, rscs, rcu-fence, and rb
> - 23. ODDS AND ENDS
> + 23. LOCKING
> + 24. ODDS AND ENDS
>
>
>
> @@ -1067,28 +1068,6 @@ allowing out-of-order writes like this t
> violating the write-write coherence rule by requiring the CPU not to
> send the W write to the memory subsystem at all!)
>
> -There is one last example of preserved program order in the LKMM: when
> -a load-acquire reads from an earlier store-release. For example:
> -
> - smp_store_release(&x, 123);
> - r1 = smp_load_acquire(&x);
> -
> -If the smp_load_acquire() ends up obtaining the 123 value that was
> -stored by the smp_store_release(), the LKMM says that the load must be
> -executed after the store; the store cannot be forwarded to the load.
> -This requirement does not arise from the operational model, but it
> -yields correct predictions on all architectures supported by the Linux
> -kernel, although for differing reasons.
> -
> -On some architectures, including x86 and ARMv8, it is true that the
> -store cannot be forwarded to the load. On others, including PowerPC
> -and ARMv7, smp_store_release() generates object code that starts with
> -a fence and smp_load_acquire() generates object code that ends with a
> -fence. The upshot is that even though the store may be forwarded to
> -the load, it is still true that any instruction preceding the store
> -will be executed before the load or any following instructions, and
> -the store will be executed before any instruction following the load.
> -
>
> AND THEN THERE WAS ALPHA
> ------------------------
> @@ -1766,6 +1745,147 @@ before it does, and the critical section
> grace period does and ends after it does.
>
>
> +LOCKING
> +-------
> +
> +The LKMM includes locking. In fact, there is special code for locking
> +in the formal model, added in order to make tools run faster.
> +However, this special code is intended to be more or less equivalent
> +to concepts we have already covered. A spinlock_t variable is treated
> +the same as an int, and spin_lock(&s) is treated almost the same as:
> +
> + while (cmpxchg_acquire(&s, 0, 1) != 0)
> + cpu_relax();
> +
> +This waits until s is equal to 0 and then atomically sets it to 1,
> +and the read part of the cmpxchg operation acts as an acquire fence.
> +An alternate way to express the same thing would be:
> +
> + r = xchg_acquire(&s, 1);
> +
> +along with a requirement that at the end, r = 0. Similarly,
> +spin_trylock(&s) is treated almost the same as:
> +
> + return !cmpxchg_acquire(&s, 0, 1);
> +
> +which atomically sets s to 1 if it is currently equal to 0 and returns
> +true if it succeeds (the read part of the cmpxchg operation acts as an
> +acquire fence only if the operation is successful). spin_unlock(&s)
> +is treated almost the same as:
> +
> + smp_store_release(&s, 0);
> +
> +The "almost" qualifiers above need some explanation. In the LKMM, the
> +store-release in a spin_unlock() and the load-acquire which forms the
> +first half of the atomic rmw update in a spin_lock() or a successful
> +spin_trylock() -- we can call these things lock-releases and
> +lock-acquires -- have two properties beyond those of ordinary releases
> +and acquires.
> +
> +First, when a lock-acquire reads from a lock-release, the LKMM
> +requires that every instruction po-before the lock-release must
> +execute before any instruction po-after the lock-acquire. This would
> +naturally hold if the release and acquire operations were on different
> +CPUs, but the LKMM says it holds even when they are on the same CPU.
> +For example:
> +
> + int x, y;
> + spinlock_t s;
> +
> + P0()
> + {
> + int r1, r2;
> +
> + spin_lock(&s);
> + r1 = READ_ONCE(x);
> + spin_unlock(&s);
> + spin_lock(&s);
> + r2 = READ_ONCE(y);
> + spin_unlock(&s);
> + }
> +
> + P1()
> + {
> + WRITE_ONCE(y, 1);
> + smp_wmb();
> + WRITE_ONCE(x, 1);
> + }
> +
> +Here the second spin_lock() reads from the first spin_unlock(), and
> +therefore the load of x must execute before the load of y. Thus we
> +cannot have r1 = 1 and r2 = 0 at the end (this is an instance of the
> +MP pattern).
> +
> +This requirement does not apply to ordinary release and acquire
> +fences, only to lock-related operations. For instance, suppose P0()
> +in the example had been written as:
> +
> + P0()
> + {
> + int r1, r2, r3;
> +
> + r1 = READ_ONCE(x);
> + smp_store_release(&s, 1);
> + r3 = smp_load_acquire(&s);
> + r2 = READ_ONCE(y);
> + }
> +
> +Then the CPU would be allowed to forward the s = 1 value from the
> +smp_store_release() to the smp_load_acquire(), executing the
> +instructions in the following order:
> +
> + r3 = smp_load_acquire(&s); // Obtains r3 = 1
> + r2 = READ_ONCE(y);
> + r1 = READ_ONCE(x);
> + smp_store_release(&s, 1); // Value is forwarded
> +
> +and thus it could load y before x, obtaining r2 = 0 and r1 = 1.
> +
> +Second, when a lock-acquire reads from a lock-release, and some other
> +stores W and W' occur po-before the lock-release and po-after the
> +lock-acquire respectively, the LKMM requires that W must propagate to
> +each CPU before W' does. For example, consider:
> +
> + int x, y;
> + spinlock_t x;
> +
> + P0()
> + {
> + spin_lock(&s);
> + WRITE_ONCE(x, 1);
> + spin_unlock(&s);
> + }
> +
> + P1()
> + {
> + int r1;
> +
> + spin_lock(&s);
> + r1 = READ_ONCE(x);
> + WRITE_ONCE(y, 1);
> + spin_unlock(&s);
> + }
> +
> + P2()
> + {
> + int r2, r3;
> +
> + r2 = READ_ONCE(y);
> + smp_rmb();
> + r3 = READ_ONCE(x);
> + }
> +
> +If r1 = 1 at the end then the spin_lock() in P1 must have read from
> +the spin_unlock() in P0. Hence the store to x must propagate to P2
> +before the store to y does, so we cannot have r2 = 1 and r3 = 0.
> +
> +These two special requirements for lock-release and lock-acquire do
> +not arise from the operational model. Nevertheless, kernel developers
> +have come to expect and rely on them because they do hold on all
> +architectures supported by the Linux kernel, albeit for various
> +differing reasons.
> +
> +
> ODDS AND ENDS
> -------------
>
> @@ -1831,26 +1951,6 @@ they behave as follows:
> events and the events preceding them against all po-later
> events.
>
> -The LKMM includes locking. In fact, there is special code for locking
> -in the formal model, added in order to make tools run faster.
> -However, this special code is intended to be exactly equivalent to
> -concepts we have already covered. A spinlock_t variable is treated
> -the same as an int, and spin_lock(&s) is treated the same as:
> -
> - while (cmpxchg_acquire(&s, 0, 1) != 0)
> - cpu_relax();
> -
> -which waits until s is equal to 0 and then atomically sets it to 1,
> -and where the read part of the atomic update is also an acquire fence.
> -An alternate way to express the same thing would be:
> -
> - r = xchg_acquire(&s, 1);
> -
> -along with a requirement that at the end, r = 0. spin_unlock(&s) is
> -treated the same as:
> -
> - smp_store_release(&s, 0);
> -
> Interestingly, RCU and locking each introduce the possibility of
> deadlock. When faced with code sequences such as:
>
>
next prev parent reply other threads:[~2018-07-10 19:57 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 20:01 [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire Alan Stern
2018-07-09 21:45 ` Paul E. McKenney
2018-07-10 13:57 ` Alan Stern
2018-07-10 16:25 ` Paul E. McKenney
[not found] ` <Pine.LNX.4.44L0.1807101416390.1449-100000@iolanthe.rowland.org>
2018-07-10 19:58 ` Paul E. McKenney [this message]
2018-07-10 20:24 ` [PATCH v3] " Alan Stern
2018-07-10 20:31 ` Paul E. McKenney
2018-07-11 9:43 ` Will Deacon
2018-07-11 15:42 ` Paul E. McKenney
2018-07-11 16:17 ` Andrea Parri
2018-07-11 18:03 ` Paul E. McKenney
2018-07-11 16:34 ` Peter Zijlstra
2018-07-11 18:10 ` Paul E. McKenney
2018-07-10 9:38 ` [PATCH v2] " Andrea Parri
2018-07-10 14:48 ` Alan Stern
2018-07-10 15:24 ` Andrea Parri
2018-07-10 15:34 ` Alan Stern
2018-07-10 23:14 ` Andrea Parri
2018-07-11 9:43 ` Will Deacon
2018-07-11 12:34 ` Andrea Parri
2018-07-11 12:54 ` Andrea Parri
2018-07-11 15:57 ` Will Deacon
2018-07-11 16:28 ` Andrea Parri
2018-07-11 17:00 ` Peter Zijlstra
2018-07-11 17:50 ` Daniel Lustig
2018-07-12 8:34 ` Andrea Parri
2018-07-12 9:29 ` Peter Zijlstra
2018-07-12 7:40 ` Peter Zijlstra
2018-07-12 9:34 ` Peter Zijlstra
2018-07-12 9:45 ` Will Deacon
2018-07-13 2:17 ` Daniel Lustig
2018-07-12 11:52 ` Andrea Parri
2018-07-12 12:01 ` Andrea Parri
2018-07-12 12:11 ` Peter Zijlstra
2018-07-12 13:48 ` Peter Zijlstra
2018-07-12 16:19 ` Paul E. McKenney
2018-07-12 17:04 ` Alan Stern
2018-07-12 17:14 ` Will Deacon
2018-07-12 17:28 ` Paul E. McKenney
2018-07-12 18:05 ` Peter Zijlstra
2018-07-12 18:10 ` Linus Torvalds
2018-07-12 19:52 ` Andrea Parri
2018-07-12 20:24 ` Andrea Parri
2018-07-13 2:05 ` Daniel Lustig
2018-07-13 4:03 ` Paul E. McKenney
2018-07-13 9:07 ` Andrea Parri
2018-07-13 9:35 ` Will Deacon
2018-07-13 17:16 ` Linus Torvalds
2018-07-13 19:06 ` Andrea Parri
2018-07-14 1:51 ` Alan Stern
2018-07-14 2:58 ` Linus Torvalds
2018-07-16 2:31 ` Paul E. McKenney
2018-07-13 11:08 ` Peter Zijlstra
2018-07-13 13:15 ` Michael Ellerman
2018-07-13 16:42 ` Peter Zijlstra
2018-07-13 19:56 ` Andrea Parri
2018-07-16 14:40 ` Michael Ellerman
2018-07-16 19:01 ` Peter Zijlstra
2018-07-16 19:30 ` Linus Torvalds
2018-07-17 14:45 ` Michael Ellerman
2018-07-17 16:19 ` Linus Torvalds
2018-07-17 18:33 ` Paul E. McKenney
2018-07-17 18:42 ` Peter Zijlstra
2018-07-17 19:40 ` Paul E. McKenney
2018-07-17 19:47 ` Alan Stern
2018-07-17 18:44 ` Linus Torvalds
2018-07-17 18:49 ` Linus Torvalds
2018-07-17 19:42 ` Paul E. McKenney
2018-07-17 19:37 ` Alan Stern
2018-07-17 20:13 ` Linus Torvalds
2018-07-17 19:38 ` Paul E. McKenney
2018-07-17 19:40 ` Andrea Parri
2018-07-17 19:52 ` Paul E. McKenney
2018-07-18 12:31 ` Michael Ellerman
2018-07-18 13:16 ` Michael Ellerman
2018-07-12 17:52 ` Andrea Parri
2018-07-12 20:43 ` Alan Stern
2018-07-12 21:13 ` Andrea Parri
2018-07-12 21:23 ` Andrea Parri
2018-07-12 18:33 ` Peter Zijlstra
2018-07-12 17:45 ` Andrea Parri
2018-07-10 16:56 ` Daniel Lustig
[not found] ` <Pine.LNX.4.44L0.1807101315140.1449-100000@iolanthe.rowland.org>
2018-07-10 23:31 ` Andrea Parri
2018-07-11 14:19 ` Alan Stern
[not found] <3344e7aeb09644758860ac343bd757a1@AcuMS.aculab.com>
2018-07-11 17:36 ` [PATCH v3] " Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180710195853.GC3593@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).