Messages in this thread Patch in this message | | | From | Will Deacon <> | Subject | [RESEND PATCH] documentation: memory-barriers: fix smp_mb__before_spinlock() semantics | Date | Tue, 31 Mar 2015 09:39:41 +0100 |
| |
Our current documentation claims that, when followed by an ACQUIRE, smp_mb__before_spinlock() orders prior loads against subsequent loads and stores, which isn't actually true.
Fix the documentation to state that this sequence orders only prior stores against subsequent loads and stores.
Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Will Deacon <will.deacon@arm.com> ---
Could somebody pick this up please? I guess I could route it via the arm64 tree with an Ack, but I'd rather it went through Paul or -tip.
Documentation/memory-barriers.txt | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index ca2387ef27ab..fa28a0c1e2b1 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1768,10 +1768,9 @@ for each construct. These operations all imply certain barriers: Memory operations issued before the ACQUIRE may be completed after the ACQUIRE operation has completed. An smp_mb__before_spinlock(), - combined with a following ACQUIRE, orders prior loads against - subsequent loads and stores and also orders prior stores against - subsequent stores. Note that this is weaker than smp_mb()! The - smp_mb__before_spinlock() primitive is free on many architectures. + combined with a following ACQUIRE, orders prior stores against + subsequent loads and stores. Note that this is weaker than smp_mb()! + The smp_mb__before_spinlock() primitive is free on many architectures. (2) RELEASE operation implication: -- 2.1.4
| |