On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote: > That would fix the problem with smp_mb__after_unlock_lock(), but not > the original worry we had about loads happening before the SC in lock. However I think isync fixes *that* :-) The problem with isync is as you said, it's not a -memory- barrier per-se, it's an execution barrier / context synchronizing instruction. The combination stwcx. + bne + isync however prevents the execution of anything past the isync until the stwcx has completed and the bne has been "decided", which prevents loads from leaking into the LL/SC loop. It will also prevent a store in the lock from being issued before the stwcx. has completed. It does *not* prevent as far as I can tell another unrelated store before the lock from leaking into the lock, including the one used to unlock a different lock. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
