Messages in this thread Patch in this message | | | Date | Wed, 18 Oct 2023 12:11:58 +0200 | Subject | Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler transformation and address deps | From | Jonas Oberhauser <> |
| |
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@joelfernandes.org> >> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> >> >> 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
| |