[lkml]   [2007]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] pi-futex: set PF_EXITING without taking ->pi_lock
    On 07/21, Ingo Molnar wrote:
    > * Oleg Nesterov <> wrote:
    > > static inline void ccids_read_lock(void)
    > > {
    > > atomic_inc(&ccids_lockct);
    > > spin_unlock_wait(&ccids_lock);
    > > }
    > >
    > > This looks racy, in theory atomic_inc() and spin_unlock_wait() could
    > > be re-ordered. However, in this particular case we have an "optimized"
    > > smp_mb_after_atomic_inc(), perhaps it is good that the caller can
    > > choose the "right" barrier by hand.
    > _all_ default locking and atomic APIs should be barrier-safe i believe.
    > (and that includes atomic_inc() too) Most people dont have barriers on
    > their mind when their code. _If_ someone is barrier-conscious then we
    > should have barrier-less APIs too for that purpose of squeezing the last
    > half cycle out of the code, but it should be a non-default choice. The
    > reason: nobody notices an unnecessary barrier, but a missing barrier can
    > be nasty.

    Personally, I agree (but I am not sure the idea to make atomic_inc()
    barrier-safe would be very popular).

    Question: should we make spinlock_t barrier-safe?

    Suppose that the task "p" does

    current->state = TASK_INTERRUPIBLE;

    if (CONDITION)


    and another CPU does

    CONDITION = 1;

    This is commonly used, but not correct _in theory_. If wake_up() happens
    when p->array != NULL, we have

    CONDITION = 1; // [1]
    task->state = TASK_RUNNING; // [2]

    and we can miss an event. Because in theory [1] may leak into the critical
    section, and could be re-ordered with [2].

    Another problem is that try_to_wake_up() first checks task->state and does
    nothing if it is TASK_RUNNING, so we need a full mb(), not just wmb().

    Should we change spin_lock(), or introduce smp_mb_before_spinlock(), or I
    missed something?

    NOTE: I do not pretend to know what kind of barrier spin_lock() provides
    in practice, but according to the documentation lock() is only a one-way

    (I am glad I have an opportunity to raise this issue again :)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-21 18:41    [W:0.032 / U:1.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site