On Thu, Mar 26, 2015 at 02:41:54PM +0000, Will Deacon wrote: > > +++ b/lib/lockref.c > > @@ -18,7 +18,8 @@ > > #define CMPXCHG_LOOP(CODE, SUCCESS) do { > > \ > > struct lockref old; > > \ > > BUILD_BUG_ON(sizeof(old) != 8); > > \ > > - old.lock_count = READ_ONCE(lockref->lock_count); > > \ > > + barrier(); > > \ > > + old.lock_count = lockref->lock_count; > > \ > > while (likely(arch_spin_value_unlocked(old.lock.rlock.raw_lock))) { > > \ > > struct lockref new = old, prev = old; > > \ > > CODE > > \ > > Is ACCESS_ONCE actually going away?
I've been arguing for that yes, having two APIs for the 'same' thing is confusing at best, and as the comment near the READ_ONCE() thing explains, ACCESS_ONCE() has serious, silent, issues. > It has its problems, but I think it's > what we want here and reads better than magic barrier() imo. Yeah, but its also misleading because we rely on silent fail. Part of the ACCESS_ONCE() semantics is that it should avoid split loads, and we're here actually relying on emitting just that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/