On Tue, Dec 10, 2013 at 06:04:04PM +0100, Oleg Nesterov wrote: > On 12/09, Paul E. McKenney wrote: > > > > This commit therefore adds a smp_mb__after_unlock_lock(), which may be > > placed after a LOCK primitive to restore the full-memory-barrier semantic. > > All definitions are currently no-ops, but will be upgraded for some > > architectures when queued locks arrive. > > I am wondering, perhaps smp_mb__after_unlock() makes more sense? > > Note that it already has the potential user: > > --- x/kernel/sched/wait.c > +++ x/kernel/sched/wait.c > @@ -176,8 +176,9 @@ prepare_to_wait(wait_queue_head_t *q, wa > spin_lock_irqsave(&q->lock, flags); > if (list_empty(&wait->task_list)) > __add_wait_queue(q, wait); > - set_current_state(state); > + __set_current_state(state); > spin_unlock_irqrestore(&q->lock, flags); > + smp_mb__after_unlock(); > } > EXPORT_SYMBOL(prepare_to_wait); > > @@ -190,8 +191,9 @@ prepare_to_wait_exclusive(wait_queue_hea > spin_lock_irqsave(&q->lock, flags); > if (list_empty(&wait->task_list)) > __add_wait_queue_tail(q, wait); > - set_current_state(state); > + __set_current_state(state); > spin_unlock_irqrestore(&q->lock, flags); > + smp_mb__after_unlock(); > } > EXPORT_SYMBOL(prepare_to_wait_exclusive); > > > Assuming it can also be used "later", after another LOCK, like in > your example in 5/7. I am fine either way. But there was an objection to tying this to the unlock because it costs more on many architectures than tying this to the lock. But if you are saying "in addition to" rather than "instead of" that would be a different conversation. Thanx, Paul -- 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
