doc: Clarify historical disclaimers in memory-barriers.txt

This commit makes it clear that the reason that these sections are
historical is that smp_read_barrier_depends() is no more.  It also
removes the point about comparison operations, given that there are
other optimizations that can break address dependencies.

Suggested-by: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrea Parri <parri.andrea@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jade Alglave <j.alglave@ucl.ac.uk>
Cc: Luc Maranget <luc.maranget@inria.fr>
Cc: Akira Yokosawa <akiyks@gmail.com>
Cc: Daniel Lustig <dlustig@nvidia.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: <linux-arch@vger.kernel.org>
Cc: <linux-doc@vger.kernel.org>
Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
This commit is contained in:
Paul E. McKenney 2023-10-20 11:04:27 -07:00 committed by Neeraj Upadhyay (AMD)
parent c49956be75
commit ad94463029
1 changed files with 10 additions and 7 deletions

View File

@ -396,10 +396,11 @@ Memory barriers come in four basic varieties:
(2) Address-dependency barriers (historical). (2) Address-dependency barriers (historical).
[!] This section is marked as HISTORICAL: For more up-to-date [!] This section is marked as HISTORICAL: it covers the long-obsolete
information, including how compiler transformations related to pointer smp_read_barrier_depends() macro, the semantics of which are now
comparisons can sometimes cause problems, see implicit in all marked accesses. For more up-to-date information,
Documentation/RCU/rcu_dereference.rst. including how compiler transformations can sometimes break address
dependencies, see Documentation/RCU/rcu_dereference.rst.
An address-dependency barrier is a weaker form of read barrier. In the An address-dependency barrier is a weaker form of read barrier. In the
case where two loads are performed such that the second depends on the case where two loads are performed such that the second depends on the
@ -560,9 +561,11 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
ADDRESS-DEPENDENCY BARRIERS (HISTORICAL) ADDRESS-DEPENDENCY BARRIERS (HISTORICAL)
---------------------------------------- ----------------------------------------
[!] This section is marked as HISTORICAL: For more up-to-date information, [!] This section is marked as HISTORICAL: it covers the long-obsolete
including how compiler transformations related to pointer comparisons can smp_read_barrier_depends() macro, the semantics of which are now implicit
sometimes cause problems, see Documentation/RCU/rcu_dereference.rst. in all marked accesses. For more up-to-date information, including
how compiler transformations can sometimes break address dependencies,
see Documentation/RCU/rcu_dereference.rst.
As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for
DEC Alpha, which means that about the only people who need to pay attention DEC Alpha, which means that about the only people who need to pay attention