On Tue, May 13, 2014 at 08:27:19AM -0700, Paul E. McKenney wrote:
> > Subject: doc: Update wakeup barrier documentation
> >
> > As per commit e0acd0a68ec7 ("sched: fix the theoretical signal_wake_up()
> > vs schedule() race") both wakeup and schedule now imply a full barrier.
> >
> > Furthermore, the barrier is unconditional when calling try_to_wake_up()
> > and has been for a fair while.
> >
> > Cc: Oleg Nesterov <o...@redhat.com>
> > Cc: Linus Torvalds <torva...@linux-foundation.org>
> > Cc: David Howells <dhowe...@redhat.com>
> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> > Signed-off-by: Peter Zijlstra <pet...@infradead.org>
>
> Some questions below.
>
> Thanx, Paul
>
> > ---
> > Documentation/memory-barriers.txt | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/memory-barriers.txt
> > b/Documentation/memory-barriers.txt
> > index 46412bded104..dae5158c2382 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -1881,9 +1881,9 @@ The whole sequence above is available in various
> > canned forms, all of which
> > event_indicated = 1;
> > wake_up_process(event_daemon);
> >
> > -A write memory barrier is implied by wake_up() and co. if and only if they
> > wake
> > -something up. The barrier occurs before the task state is cleared, and so
> > sits
> > -between the STORE to indicate the event and the STORE to set TASK_RUNNING:
> > +A full memory barrier is implied by wake_up() and co. The barrier occurs
>
> Last I checked, the memory barrier was guaranteed only if a wakeup
> actually occurred. If there is a sleep-wakeup race, for example,
> between wait_event_interruptible() and wake_up(), then it looks to me
> that the following can happen:
>
> o Task A invokes wait_event_interruptible(), waiting for
> X==1.
>
> o Before Task A gets anywhere, Task B sets Y=1, does
> smp_mb(), then sets X=1.
>
> o Task B invokes wake_up(), which invokes __wake_up(), which
> acquires the wait_queue_head_t's lock and invokes
> __wake_up_common(), which sees nothing to wake up.
>
> o Task A tests the condition, finds X==1, and returns without
> locks, memory barriers, atomic instructions, or anything else
> that would guarantee ordering.
>
> o Task A then loads from Y. Because there have been no memory
> barriers, it might well see Y==0.
>
> So what am I missing here?
Ah, that's what was meant :-) The way I read it was that
wake_up_process() would only imply the barrier if the task actually got
a wakeup (ie. the return value is 1).
But yes, this makes a lot more sense. Sorry for the confusion.
> On the wake_up() side, wake_up() calls __wake_up(), which as mentioned
> earlier calls __wake_up_common() under a lock. This invokes the
> wake-up function stored by the sleeping task, for example,
> autoremove_wake_function(), which calls default_wake_function(),
> which invokes try_to_wake_up(), which does smp_mb__before_spinlock()
> before acquiring the to-be-waked task's PI lock.
>
> The definition of smp_mb__before_spinlock() is smp_wmb(). There is
> also an smp_rmb() in try_to_wake_up(), which still does not get us
> to a full memory barrier. It also calls select_task_rq(), which
> does not seem to guarantee any particular memory ordering (but
> I could easily have missed something). It also calls ttwu_queue(),
> which invokes ttwu_do_activate() under the RQ lock. I don't see a
> full memory barrier in ttwu_do_activate(), but again could easily
> have missed one. Ditto for ttwu_stat().
Ah, yes, so I'll defer to Oleg and Linus to explain that one. As per the
name: smp_mb__before_spinlock() should of course imply a full barrier.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
