Messages in this thread | | | Date | Wed, 11 Nov 2015 20:53:54 +0100 | From | Oleg Nesterov <> | Subject | Re: [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.
| |