Messages in this thread | | | Date | Wed, 17 Jun 2015 08:42:45 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 11/18] seqcount: Introduce raw_write_seqcount_barrier() |
| |
On Wed, Jun 17, 2015 at 05:11:09PM +0200, Peter Zijlstra wrote: > On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote: > > On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote: > > > I did leave off the READ/WRITE ONCE stuff, because I could not come up > > > with a scenario where it makes a difference -- I appreciate paranoia, > > > but I also think we should not overdo the thing. > > > > I can only conclude that you have not read this document: > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html > > This would be correct. > > > Specifically, please keep in mind that unless you mark either the variable > > or the memory access, the compiler is within its rights to assume that > > there are no concurrent accesses to that variable. For but one example, > > if you do a normal store to a given variable, then the compiler is > > within its rights to use that variable as temporary storage prior to > > that store. And yes, you can reasonably argue that no sane compiler > > would store something else to s->sequence given that it could free up > > a register by storing the incremented value, but the fact remains that > > you have given it permission to do so if it wants. > > Argh *grmbl*, that's bloody insane!
You expected me to argue with that statement? ;-)
> So I get the re-loading, I get the tearing, but this random intermittent > values (somewhat related to stores out of thin air) is completely > bonkers. > > I would very much prefer a compiler switch that instructs the compiler > to not do bloody stupid things like this instead of marking every other > load/store in the kernel with volatile.
I would of course be good with such a compiler switch, though my earlier attempts to negotiate one were unsuccessful. But I don't believe that we discussed a switch to specifically prohibit only use of to-be-stored-into variables as temporary scratch space. The trick is finding restrictions that are useful, but that don't imply -O0.
Any GCC or LLVM folks on the list?
> Note that if GCC were to actually do something like this, the kernel > would already be broken, because I'm very sure we did not consider/audit > it for this.
An accident waiting to happen, given that both GCC and the Linux kernel are moving targets. :-/
Thanx, Paul
| |