The barrier parings for wake-queues are very straightforward, and thus we can ease the barrier requirements, for archs that support it, for wake_q_add by relying on acquire semantics. As such, (i) we keep the pairing structure/logic and (ii) users, such as mqueues, can continue to rely on a full barrier after the successful [Rmw].
[Another alternative could be to just not try at all and fully downgrade to cmpxchg_relaxed() and rely on users to enable their own synchronization. But controlling this ourselves makes me sleep better at night.] Signed-off-by: Davidlohr Bueso <[email protected]> --- kernel/sched/core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 6ab415a..7567603 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -523,14 +523,14 @@ void wake_q_add(struct wake_q_head *head, struct task_struct *task) struct wake_q_node *node = &task->wake_q; /* - * Atomically grab the task, if ->wake_q is !nil already it means - * its already queued (either by us or someone else) and will get the - * wakeup due to that. + * Atomically grab the task. If ->wake_q is non-nil (failed cmpxchg) + * then the task is already queued (by us or someone else) and will + * get the wakeup due to that. * - * This cmpxchg() implies a full barrier, which pairs with the write - * barrier implied by the wakeup in wake_up_list(). + * Use acquire semantics to add the next pointer, which pairs with the + * write barrier implied by the wakeup in wake_up_list(). */ - if (cmpxchg(&node->next, NULL, WAKE_Q_TAIL)) + if (cmpxchg_acquire(&node->next, NULL, WAKE_Q_TAIL)) return; get_task_struct(task); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
