[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1445975631-17047-5-git-send-email-dave@stgolabs.net>
Date: Tue, 27 Oct 2015 12:53:51 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, dave@...olabs.net,
linux-kernel@...r.kernel.org
Subject: [PATCH 4/4] doc,smp: Remove ambiguous statement in smp_store_mb()
It serves no purpose but to confuse readers, and is most
likely a left over from constant memory-barriers.txt
updates. Ie:
http://lists.openwall.net/linux-kernel/2006/07/15/27
Signed-off-by: Davidlohr Bueso <dave@...olabs.net>
---
Documentation/memory-barriers.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index b5fe765..ee6fbb0 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1683,8 +1683,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();
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists