From: Paul E. McKenney Date: Wed, 6 Jan 2016 22:23:03 +0000 (-0800) Subject: documentation: Fix memory-barriers.txt section references X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=895f5542220eeea43b811a9b4cd73f244c5673d7;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git 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 --- 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.