lkml.org 
[lkml]   [2015]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/4] locking: Introduce smp_cond_acquire()
    He Boqun,

    Let me first state that I can't answer authoritatively when it comes to
    barriers. That said,

    On 11/11, Boqun Feng wrote:
    >
    > But still, there is one suspicious use of smp_mb() in do_exit():
    >
    > /*
    > * The setting of TASK_RUNNING by try_to_wake_up() may be delayed
    > * when the following two conditions become true.
    > * - There is race condition of mmap_sem (It is acquired by
    > * exit_mm()), and
    > * - SMI occurs before setting TASK_RUNINNG.
    > * (or hypervisor of virtual machine switches to other guest)
    > * As a result, we may become TASK_RUNNING after becoming TASK_DEAD
    > *
    > * To avoid it, we have to wait for releasing tsk->pi_lock which
    > * is held by try_to_wake_up()
    > */
    > smp_mb();
    > raw_spin_unlock_wait(&tsk->pi_lock);
    >
    > /* causes final put_task_struct in finish_task_switch(). */
    > tsk->state = TASK_DEAD;
    > tsk->flags |= PF_NOFREEZE; /* tell freezer to ignore us */
    > schedule();
    >
    > Seems like smp_mb() doesn't need here?

    Please see my reply to peterz's email.

    AFAICS, we need the barries on both sides. But, since we only need to
    STORE into tsk->state after unlock_wait(), we can rely on the control
    dependency and avoid the 2nd mb().

    Oleg.



    \
     
     \ /
      Last update: 2015-11-11 20:21    [W:2.987 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site