On Tue, Apr 02, 2013 at 09:25:40PM -0700, David Rientjes wrote: > On Wed, 3 Apr 2013, Johannes Weiner wrote: > > > The definition of ACCESS_ONCE() relies on gcc's current > > implementation, the users of ACCESS_ONCE() only rely on ACCESS_ONCE() > > being defined. > > > > Should it ever break you have to either fix it at the implementation > > level or remove/replace the abstraction in its entirety, how does the > > individual callsite matter in this case? > > > > As stated, it doesn't. I made the comment "for what it's worth" that > ACCESS_ONCE() doesn't do anything to "prevent the compiler from > re-fetching" as the changelog insists it does. That's exactly what it does: /* * Prevent the compiler from merging or refetching accesses. This is the guarantee ACCESS_ONCE() gives, users should absolutely be allowed to rely on this literal definition. The underlying gcc implementation does not matter one bit. That's the whole point of abstraction! > I'd much rather it refer to gcc's implementation, which we're > counting on here, No, we really don't. There is no "(*(volatile typeof(x)*)&(x))" anywhere in this patch. > to avoid any confusion since I know a couple people have thought > that ACCESS_ONCE() forces the compiler to load memory onto the stack > and that belief is completely and utterly wrong. Maybe "forces the compiler to load memory onto the stack" should be removed from the documentation of ACCESS_ONCE() then? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>