On Tue, Jan 06, 2009 at 03:25:12AM +1100, Nick Piggin wrote: > On Tuesday 06 January 2009 03:05:01 Paul E. McKenney wrote: > > On Mon, Jan 05, 2009 at 11:00:24PM +1100, Nick Piggin wrote: > > > On Monday 05 January 2009 22:23:50 Alan Cox wrote: > > > > > Pretty much everywhere that uses RCU for example does so using atomic > > > > > pointer loads and stores. The nastiest issue IMO actually is > > > > > reloading the value through the pointer even if it isn't explicitly > > > > > dereferenced. RCU gets this right with ACCESS_ONCE. Probably a lot of > > > > > code using basic types does not. x86 atomic_read maybe should be > > > > > using ACCESS_ONCE too... > > > > > > > > I'm pretty sure it should. gcc makes no guarantees about not being > > > > clever with accesses. > > > > > > Arguably it should. I don't know what the concurrent C standard looks > > > like, but prohibiting reloads of potentially concurrently modified memory > > > when there is no explicit pointer dereference is the natural complement > > > to prohibiting stores to potentially concurrently read memory when there > > > is no explicit store (which I think is begrudgingly agreed to be a > > > problem). > > > > > > http://lkml.org/lkml/2007/10/24/673 > > > > > > I think I would like to see multiple reloads to local variables > > > prohibited, to avoid potential really subtle problems... But if > > > ACCESS_ONCE is here to stay, then I do think that atomic_read etc should > > > use it. > > > > The concurrency stuff in c++0x still permits the compiler to have its > > way with loads and stores to normal variables, but provides an "atomic" > > type that must be loaded and stored as specified in the program. > > So: > if (trylock()) > locked = 1; > ... > if (locked) > *var = blah; > ... > if (locked) > unlock(); > > So the second part can still be transformed into a predicated calculation > of blah, then an unconditional store to *var? Assuming that "var" is an ordinary variable... If you are asking whether the compiler guys believe that they are within their rights to do a store to *var and then store the old value to *var if !locked, the unfortunate answer is "yes". Hence ACCESS_ONCE(). > > The issue with ACCESS_ONCE() is that gcc doesn't do any optimizations on > > volatile accesses, even the obvious ones. Speaking of which, the gcc > > guys kicked out my bug 33102, which was complaining about this > > situation. :-/ > > Hmm. It's still quite annoying even to have to switch everything to the > atomic type. I guarantee there will be bugs in Linux caused by the > compiler reloading pointers/longs/ints to access local variables... Another approach would be to change ACCESS_ONCE() to use the atomic types. Then we have a bigger hammer with which to beat the gcc guys about optimizations. We can hope, anyway... Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html