From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com,
edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com,
oleg@redhat.com, sbw@mit.edu,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
Date: Mon, 7 Jul 2014 15:24:21 -0700 [thread overview]
Message-ID: <1404771862-6904-3-git-send-email-paulmck@linux.vnet.ibm.com> (raw)
In-Reply-To: <1404771862-6904-1-git-send-email-paulmck@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
It is possible to pair acquire and release barriers with other barriers,
so this commit adds them to the list in the SMP barrier pairing section.
Reported-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
---
Documentation/memory-barriers.txt | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a6ca533a73fc..2a7c3c4fb53f 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -757,10 +757,12 @@ SMP BARRIER PAIRING
When dealing with CPU-CPU interactions, certain types of memory barrier should
always be paired. A lack of appropriate pairing is almost certainly an error.
-A write barrier should always be paired with a data dependency barrier or read
-barrier, though a general barrier would also be viable. Similarly a read
-barrier or a data dependency barrier should always be paired with at least an
-write barrier, though, again, a general barrier is viable:
+A write barrier should always be paired with a data dependency barrier,
+acquire barrier, release barrier, or read barrier, though a general
+barrier would also be viable. Similarly a read barrier or a data
+dependency barrier should always be paired with at least a write barrier,
+an acquire barrier, or a release barrier, though, again, a general
+barrier is viable:
CPU 1 CPU 2
=============== ===============
--
1.8.1.5
next prev parent reply other threads:[~2014-07-07 22:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-07 22:23 [PATCH tip/core/rcu 0/4] Documentation changes for 3.17 Paul E. McKenney
2014-07-07 22:24 ` [PATCH tip/core/rcu 1/4] documentation: Clarify wake-up/memory-barrier relationship Paul E. McKenney
2014-07-07 22:24 ` [PATCH tip/core/rcu 2/4] documentation: Update reference, kerneltrap.org no longer works Paul E. McKenney
2014-07-07 22:24 ` Paul E. McKenney [this message]
2014-07-08 7:59 ` [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules Peter Zijlstra
2014-07-08 15:31 ` Paul E. McKenney
2014-07-14 11:57 ` Peter Zijlstra
2014-07-16 12:16 ` Paul E. McKenney
2014-07-16 13:05 ` Peter Zijlstra
2014-07-16 13:18 ` Paul E. McKenney
2014-07-16 13:27 ` Mathieu Desnoyers
2014-07-07 22:24 ` [PATCH tip/core/rcu 4/4] documentation: Add pointer to percpu-ref for RCU and refcount Paul E. McKenney
2014-07-08 7:53 ` [PATCH tip/core/rcu 1/4] documentation: Clarify wake-up/memory-barrier relationship Peter Zijlstra
2014-07-08 0:14 ` [PATCH tip/core/rcu 0/4] Documentation changes for 3.17 Josh Triplett
2014-07-08 8:51 ` Lai Jiangshan
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=1404771862-6904-3-git-send-email-paulmck@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=dvhart@linux.intel.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=niv@us.ibm.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.