Messages in this thread | | | Date | Wed, 18 Oct 2017 13:28:05 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Linux-kernel examples for LKMM recipes |
| |
On Wed, Oct 18, 2017 at 10:43:42AM -0400, Alan Stern wrote: > On Tue, 17 Oct 2017, Paul E. McKenney wrote: > > > > > > > b. Compilers are permitted to use the "as-if" rule. > > > > > > That is, a compiler can emit whatever code it likes, > > > > > > as long as the results appear just as if the compiler > > > > > > had followed all the relevant rules. To see this, > > > > > > compiler with a high level of optimization and run > > > > > > the debugger on the resulting binary. > > > > > > > > > > You might omit the last sentence. Furthermore, if the accesses don't > > > > > use READ_ONCE/WRITE_ONCE then the code might not get the same result as > > > > > if it had executed in order (even for a single variable!), and if you > > > > > do use READ_ONCE/WRITE_ONCE then the compiler can't emit whatever code > > > > > it likes. > > > > > > > > Ah, I omitted an important qualifier: > > > > > > > > b. Compilers are permitted to use the "as-if" rule. That is, > > > > a compiler can emit whatever code it likes, as long as > > > > the results of a single-threaded execution appear just > > > > as if the compiler had followed all the relevant rules. > > > > To see this, compile with a high level of optimization > > > > and run the debugger on the resulting binary. > > > > > > That's okay for the single-CPU case. I don't think it covers the > > > multiple-CPU single-variable case correctly, though. If you don't use > > > READ_ONCE or WRITE_ONCE, isn't the compiler allowed to tear the loads > > > and stores? And won't that potentially cause the end result to be > > > different from what you would get if the code had appeared to execute > > > in order? > > > > Ah, good point, I need yet another qualifier. How about the following? > > > > b. Compilers are permitted to use the "as-if" rule. That is, > > a compiler can emit whatever code it likes for normal > > accesses, as long as the results of a single-threaded > > execution appear just as if the compiler had followed > > all the relevant rules. To see this, compile with a > > high level of optimization and run the debugger on the > > resulting binary. > > > > I added "for normal accesses", which excludes READ_ONCE(), WRITE_ONCE(), > > and atomics. This, in conjunction with the previously added > > "single-threaded execution" means that yes, the compiler is permitted > > to tear normal loads and stores. The reason is that a single-threaded > > run could not tell the difference. Interrupt handlers or multiple > > threads are required to detect load/store tearing. > > > > So, what am I still missing? ;-) > > Well, you could explicitly mention that in the multi-thread case, this > means all accesses to the shared variable had better use READ_ONCE() or > WRITE_ONCE().
Like this?
Thanx, Paul
------------------------------------------------------------------------
d. If there are multiple CPUs, accesses to shared variables should use READ_ONCE() and WRITE_ONCE() or stronger to prevent load/store tearing, load/store fusing, and invented loads and stores. There are exceptions to this rule, for example:
i. When there is no possibility of a given shared variable being updated, for example, while holding the update-side lock, reads from that variable need not use READ_ONCE().
ii. When there is no possibility of a given shared variable being either read or updated, for example, when running during early boot, reads from that variable need not use READ_ONCE() and writes to that variable need not use WRITE_ONCE().
| |