lkml.org 
[lkml]   [2009]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Document that wake_up(), complete() and co. imply a full memory barrier
    On 04/22, Ingo Molnar wrote:
    >
    > * David Howells <dhowells@redhat.com> wrote:
    >
    > The dangerous pattern is lockless code doing wakeups. But lockless
    > code always has to use proper barriers or atomics anyway, and has to
    > be aware of the fact that kernel primitives they call are not
    > necessarily full memory barriers.
    >
    > In fact i'd encourage to _not_ document try_to_lock() as a write
    > barrier either - but rather have explicit barriers where they are
    > needed. Then we could remove that barrier from try_to_wake_up() too
    > ;-)

    Well. I think in that case almost every try_to_wake_up/wake_up_process
    needs mb().

    For example:

    do_nanosleep:

    for (;;) {
    set_current_state(TASK_INTERRUPTIBLE);
    if (likely(t->task))
    schedule();
    break;
    }

    hrtimer_wakeup:

    task = t->task
    t->task = NULL;
    wake_up_process(task);

    If try_to_wake_up() has no the barrier semantics, we can miss the event.
    "t->task = NULL" and the reading of task->state must not be reordered.

    Oleg.



    \
     
     \ /
      Last update: 2009-04-23 18:43    [W:2.052 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site