Hi Paul,
on a second thought. Why can't the compiler always do, e.g.,
int *p = READ_ONCE(shared_ptr);
assert (*p == 0);
~>
int *p = READ_ONCE(shared_ptr);
int val = x; // x is some object that definitely won't segfault,
but may very well be owned by another thread right now
if (p != &x) val = *p;
assert (val == 0);
and in case p == &x, the address dependency is elided
Best wishes,
jonas
Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
Hi Paul,
The "more up-to-date information" makes it sound like (some of) the
information in this section is out-of-date/no longer valid.
But after reading the sections, it seems the information is valid, but
discusses mostly the history of address dependency barriers.
Given that the sepcond part specifically already starts with a
disclaimer that this information is purely relevant to people
interested in history or working on alpha, I think it would make more
sense to modify things slightly differently.
Firstly I'd remove the "historical" part in the first section, and add
two short paragraphs explaining that
- every marked access implies a address dependency barrier
- address dependencies considered by the model are *semantic*
dependencies, meaning that a *syntactic* dependency is not sufficient
to imply ordering; see the rcu file for some examples where compilers
can elide syntactic dependencies
Secondly, I'd not add the disclaimer to the second section; there's
already a link to rcu_dereference in that section (
https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt#L634
), and already a small text explaining that the section is historical.
Best wishes,
jonas
Am 10/5/2023 um 6:53 PM schrieb Paul E. McKenney:
The compiler has the ability to cause misordering by destroying
address-dependency barriers if comparison operations are used. Add a
note about this to memory-barriers.txt in the beginning of both the
historical address-dependency sections and point to rcu-dereference.rst
for more information.
Signed-off-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx>
Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 06e14efd8662..d414e145f912 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -396,6 +396,10 @@ Memory barriers come in four basic varieties:
(2) Address-dependency barriers (historical).
+ [!] This section is marked as HISTORICAL: For more up-to-date
+ information, including how compiler transformations related to
pointer
+ comparisons can sometimes cause problems, see
+ Documentation/RCU/rcu_dereference.rst.
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
@@ -556,6 +560,9 @@ There are certain things that the Linux kernel
memory barriers do not guarantee:
ADDRESS-DEPENDENCY BARRIERS (HISTORICAL)
----------------------------------------
+[!] This section is marked as HISTORICAL: For more up-to-date
information,
+including how compiler transformations related to pointer
comparisons can
+sometimes cause problems, see Documentation/RCU/rcu_dereference.rst.
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
