On 06/15/2018 06:46 PM, Peter Zijlstra wrote:
On Fri, Jun 15, 2018 at 02:08:27PM +0200, Thomas Hellstrom wrote:
@@ -772,6 +856,25 @@ __ww_mutex_add_waiter(struct mutex_waiter *waiter, } list_add_tail(&waiter->list, pos);
- if (__mutex_waiter_is_first(lock, waiter))
__mutex_set_flag(lock, MUTEX_FLAG_WAITERS);- /*
* Wound-Wait: if we're blocking on a mutex owned by a younger context,* wound that such that we might proceed.*/- if (!is_wait_die) {
struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);/** See ww_mutex_set_context_fastpath(). Orders setting* MUTEX_FLAG_WAITERS (atomic operation) vs the ww->ctx load,* such that either we or the fastpath will wound @ww->ctx.*/smp_mb__after_atomic();__ww_mutex_wound(lock, ww_ctx, ww->ctx);- }
I think we want the smp_mb__after_atomic() in the same branch as __mutex_set_flag(). So something like:
if (__mutex_waiter_is_first()) { __mutex_set_flag(); if (!is_wait_die) smp_mb__after_atomic(); }
Or possibly even without the !is_wait_die. The rules for smp_mb__*_atomic() are such that we want it unconditional after an atomic, otherwise the semantics get too fuzzy.
Alan (rightfully) complained about that a while ago when he was auditing users.
Hmm, yes that's understandable, although I must admit that when one of the accesses we want to order is actually an atomic this shouldn't really be causing much confusion.
But I'll think I'll change it back to an smp_mb() then. It's in a slowpath, and awkward constructs around smp_mb__after_atomic() might be causing grief in the future.
/Thomas