Commit b8fb65e1 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'lkmm.2022.09.30a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu

Pull LKMM (Linux Kernel Memory Model) updates from Paul McKenney:
 "Several documentation updates"

* tag 'lkmm.2022.09.30a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
  tools/memory-model: Clarify LKMM's limitations in litmus-tests.txt
  docs/memory-barriers.txt: Fixup long lines
  docs/memory-barriers.txt: Fix confusing name of 'data dependency barrier'
parents dda0ba40 be94ecf7
This diff is collapsed.
...@@ -946,22 +946,39 @@ Limitations of the Linux-kernel memory model (LKMM) include: ...@@ -946,22 +946,39 @@ Limitations of the Linux-kernel memory model (LKMM) include:
carrying a dependency, then the compiler can break that dependency carrying a dependency, then the compiler can break that dependency
by substituting a constant of that value. by substituting a constant of that value.
Conversely, LKMM sometimes doesn't recognize that a particular Conversely, LKMM will sometimes overestimate the amount of
optimization is not allowed, and as a result, thinks that a reordering compilers and CPUs can carry out, leading it to miss
dependency is not present (because the optimization would break it). some pretty obvious cases of ordering. A simple example is:
The memory model misses some pretty obvious control dependencies
because of this limitation. A simple example is:
r1 = READ_ONCE(x); r1 = READ_ONCE(x);
if (r1 == 0) if (r1 == 0)
smp_mb(); smp_mb();
WRITE_ONCE(y, 1); WRITE_ONCE(y, 1);
There is a control dependency from the READ_ONCE to the WRITE_ONCE, The WRITE_ONCE() does not depend on the READ_ONCE(), and as a
even when r1 is nonzero, but LKMM doesn't realize this and thinks result, LKMM does not claim ordering. However, even though no
that the write may execute before the read if r1 != 0. (Yes, that dependency is present, the WRITE_ONCE() will not be executed before
doesn't make sense if you think about it, but the memory model's the READ_ONCE(). There are two reasons for this:
intelligence is limited.)
The presence of the smp_mb() in one of the branches
prevents the compiler from moving the WRITE_ONCE()
up before the "if" statement, since the compiler has
to assume that r1 will sometimes be 0 (but see the
comment below);
CPUs do not execute stores before po-earlier conditional
branches, even in cases where the store occurs after the
two arms of the branch have recombined.
It is clear that it is not dangerous in the slightest for LKMM to
make weaker guarantees than architectures. In fact, it is
desirable, as it gives compilers room for making optimizations.
For instance, suppose that a 0 value in r1 would trigger undefined
behavior elsewhere. Then a clever compiler might deduce that r1
can never be 0 in the if condition. As a result, said clever
compiler might deem it safe to optimize away the smp_mb(),
eliminating the branch and any ordering an architecture would
guarantee otherwise.
2. Multiple access sizes for a single variable are not supported, 2. Multiple access sizes for a single variable are not supported,
and neither are misaligned or partially overlapping accesses. and neither are misaligned or partially overlapping accesses.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment