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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
