summaryrefslogtreecommitdiffstats
path: root/Documentation/RCU/Design/Memory-Ordering
diff options
context:
space:
mode:
authorSeongJae Park <sjpark@amazon.de>2020-01-06 21:07:56 +0100
committerPaul E. McKenney <paulmck@kernel.org>2020-02-27 16:03:13 +0100
commitd18c265fbf19de7716e6e3054b752594133b0739 (patch)
treee51fe8446c55fa22aa976c6ee41e4e3bc5046857 /Documentation/RCU/Design/Memory-Ordering
parentdoc: Add some more RCU list patterns in the kernel (diff)
downloadlinux-d18c265fbf19de7716e6e3054b752594133b0739.tar.xz
linux-d18c265fbf19de7716e6e3054b752594133b0739.zip
doc/RCU/Design: Remove remaining HTML tags in ReST files
Commit ccc9971e2147 ("docs: rcu: convert some articles from html to ReST") has converted a few of html RCU docs into ReST files, but a few of html tags which not supported on rst is remaining. This commit converts those to ReST appropriate alternatives. Reviewed-by: Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com> Signed-off-by: SeongJae Park <sjpark@amazon.de> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'Documentation/RCU/Design/Memory-Ordering')
-rw-r--r--Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst8
1 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index 1a8b129cfc04..83ae3b79a643 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -4,7 +4,7 @@ A Tour Through TREE_RCU's Grace-Period Memory Ordering
August 8, 2017
-This article was contributed by Paul E.&nbsp;McKenney
+This article was contributed by Paul E. McKenney
Introduction
============
@@ -48,7 +48,7 @@ Tree RCU Grace Period Memory Ordering Building Blocks
The workhorse for RCU's grace-period memory ordering is the
critical section for the ``rcu_node`` structure's
-``-&gt;lock``. These critical sections use helper functions for lock
+``->lock``. These critical sections use helper functions for lock
acquisition, including ``raw_spin_lock_rcu_node()``,
``raw_spin_lock_irq_rcu_node()``, and ``raw_spin_lock_irqsave_rcu_node()``.
Their lock-release counterparts are ``raw_spin_unlock_rcu_node()``,
@@ -102,9 +102,9 @@ lock-acquisition and lock-release functions::
23 r3 = READ_ONCE(x);
24 }
25
- 26 WARN_ON(r1 == 0 &amp;&amp; r2 == 0 &amp;&amp; r3 == 0);
+ 26 WARN_ON(r1 == 0 && r2 == 0 && r3 == 0);
-The ``WARN_ON()`` is evaluated at &ldquo;the end of time&rdquo;,
+The ``WARN_ON()`` is evaluated at "the end of time",
after all changes have propagated throughout the system.
Without the ``smp_mb__after_unlock_lock()`` provided by the
acquisition functions, this ``WARN_ON()`` could trigger, for example