| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20210610155029.130812-1-frederic@kernel.org>
Date: Thu, 10 Jun 2021 17:50:29 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: "Paul E . McKenney" <paulmck@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <neeraju@...eaurora.org>,
Boqun Feng <boqun.feng@...il.com>,
Uladzislau Rezki <urezki@...il.com>,
Joel Fernandes <joel@...lfernandes.org>
Subject: [PATCH] rcu/doc: Add a quick quiz to explain further why we need smp_mb__after_unlock_lock()
Add some missing critical pieces of explanation to understand the need
for full memory barriers throughout the whole grace period state machine,
thanks to Paul's explanations.
Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
Cc: Neeraj Upadhyay <neeraju@...eaurora.org>
Cc: Joel Fernandes <joel@...lfernandes.org>
Cc: Uladzislau Rezki <urezki@...il.com>
Cc: Boqun Feng <boqun.feng@...il.com>
---
.../Tree-RCU-Memory-Ordering.rst | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
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 11cdab037bff..f21432115627 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -112,6 +112,39 @@ on PowerPC.
The ``smp_mb__after_unlock_lock()`` invocations prevent this
``WARN_ON()`` from triggering.
++-----------------------------------------------------------------------+
+| **Quick Quiz**: |
++-----------------------------------------------------------------------+
+| But the whole chain of rnp locking is enough for the readers to see |
+| all the pre-grace-period accesses from the updater and for the updater|
+| to see all the accesses from the readers performed before the end of |
+| the grace period. So why do we need to enforce full ordering at all |
+| through smp_mb__after_unlock_lock()? |
++-----------------------------------------------------------------------+
+| **Answer**: |
++-----------------------------------------------------------------------+
+| Because we still need to take care of the lockless counterparts of |
+| RCU. The first key example here is grace period polling. Using |
+| poll_state_synchronize_rcu() or cond_synchronize_rcu(), an updater |
+| can rely solely on lockess full ordering to benefit from the usual |
+| TREE RCU ordering guarantees. |
+| |
+| The second example lays behind the fact that a grace period still |
+| claims to imply full memory ordering. Therefore in the following |
+| scenario: |
+| |
+| CPU 0 CPU 1 |
+| ---- ---- |
+| WRITE_ONCE(X, 1) WRITE_ONCE(Y, 1) |
+| synchronize_rcu() smp_mb() |
+| r0 = READ_ONCE(Y) r1 = READ_ONCE(X) |
+| |
+| It must be impossible to have r0 == 0 && r1 == 0 after both CPUs |
+| have completed their sequences, even if CPU 1 is in an RCU extended |
+| quiescent state (idle mode) and thus won't report a quiescent state |
+| throughout the common rnp locking chain. |
++-----------------------------------------------------------------------+
+
This approach must be extended to include idle CPUs, which need
RCU's grace-period memory ordering guarantee to extend to any
RCU read-side critical sections preceding and following the current
--
2.25.1
Powered by blists - more mailing lists