Skip to content

Commit

Permalink
locking/barriers, arch: Remove ambiguous statement in the smp_store_m…
Browse files Browse the repository at this point in the history
…b() documentation

It serves no purpose but to confuse readers, and is most
likely a left over from constant memory-barriers.txt
updates. I.e.:

  http://lists.openwall.net/linux-kernel/2006/07/15/27

Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <linux-arch@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1445975631-17047-5-git-send-email-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
  • Loading branch information
Davidlohr Bueso authored and Ingo Molnar committed Dec 4, 2015
1 parent d5a73ca commit 2d142e5
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions Documentation/memory-barriers.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1673,8 +1673,8 @@ There are some more advanced barrier functions:
(*) smp_store_mb(var, value)

This assigns the value to the variable and then inserts a full memory
barrier after it, depending on the function. It isn't guaranteed to
insert anything more than a compiler barrier in a UP compilation.
barrier after it. It isn't guaranteed to insert anything more than a
compiler barrier in a UP compilation.


(*) smp_mb__before_atomic();
Expand Down

0 comments on commit 2d142e5

Please sign in to comment.