diff options
| author | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2016-01-06 14:23:03 -0800 |
|---|---|---|
| committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2016-03-14 15:52:16 -0700 |
| commit | 895f5542220eeea43b811a9b4cd73f244c5673d7 (patch) | |
| tree | dd575083c20c36a1a1e50a9848089d703467f949 | |
| parent | 7817b799ed6b270fbf7f2b30efd0ae011dfc9644 (diff) | |
documentation: Fix memory-barriers.txt section references
This commit fixes a couple of "Compiler Barrier" section references to
be "COMPILER BARRIER". This makes it easier to find the section in
the usual text editors.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
| -rw-r--r-- | Documentation/memory-barriers.txt | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index e26058d3e253..c90922b9b294 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -232,7 +232,7 @@ And there are a number of things that _must_ or _must_not_ be assumed: with memory references that are not protected by READ_ONCE() and WRITE_ONCE(). Without them, the compiler is within its rights to do all sorts of "creative" transformations, which are covered in - the Compiler Barrier section. + the COMPILER BARRIER section. (*) It _must_not_ be assumed that independent loads and stores will be issued in the order given. This means that for: @@ -818,7 +818,7 @@ In summary: (*) Control dependencies require that the compiler avoid reordering the dependency into nonexistence. Careful use of READ_ONCE() or atomic{,64}_read() can help to preserve your control dependency. - Please see the Compiler Barrier section for more information. + Please see the COMPILER BARRIER section for more information. (*) Control dependencies pair normally with other types of barriers. |