On Mon, Nov 25, 2013 at 10:52:10AM -0800, H. Peter Anvin wrote: > On 11/25/2013 09:35 AM, Peter Zijlstra wrote: > > > > I think this means x86 needs help too. > > > > Consider: > > > > x = y = 0 > > > > w[x] = 1 | w[y] = 1 > > mfence | mfence > > r[y] = 0 | r[x] = 0 > > > > This is generally an impossible case, right? (Since if we observe y=0 > > this means that w[y]=1 has not yet happened, and therefore x=1, and > > vice-versa). > > > > Now replace one of the mfences with smp_store_release(l1); > > smp_load_acquire(l2); such that we have a RELEASE+ACQUIRE pair that > > _should_ form a full barrier: > > > > w[x] = 1 | w[y] = 1 > > w[l1] = 1 | mfence > > r[l2] = 0 | r[x] = 0 > > r[y] = 0 | > > > > At which point we can observe the impossible, because as per the rule: > > > > 'reads may be reordered with older writes to different locations' > > > > Our r[y] can slip before the w[x]=1. > > Yes, because although r[l2] and r[y] are ordered with respect to each > other, they are allowed to be executed before w[x] and w[l1]. In other > words, smp_store_release() followed by smp_load_acquire() to a different > location do not form a full barrier. To the *same* location, they will. In the case where we have a single CPU doing an unlock of one lock followed by a lock of another lock using Tim Chen's MCS lock, there will be an xchg() that will provide the needed full barrier. If the unlock is from one CPU and the lock is from another CPU, then Linux kernel only requires a full barrier in the case where both the unlock and lock are acting on the same lock variable. Which is the scenario under investigation. Thanx, Paul -- 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>