Re: [tip:locking/core] sched/core: Fix an SMP ordering race in try_to_wake_up() vs. schedule()

* Re: [tip:locking/core] sched/core: Fix an SMP ordering race in try_to_wake_up() vs. schedule()
       [not found] <tip-ecf7d01c229d11a44609c0067889372c91fb4f36@git.kernel.org>
@ 2016-10-07  1:36 ` Mike Galbraith
  2016-10-07  6:38   ` Jiri Slaby
  2016-10-07  8:29   ` Peter Zijlstra
  0 siblings, 2 replies; 4+ messages in thread
From: Mike Galbraith @ 2016-10-07  1:36 UTC (permalink / raw)
  To: stable; +Cc: peterz, Ingo Molnar, Oleg Nesterov, linux-tip-commits

Seems this may be one of those not so theoretical races.  A humongous
ppc64 box actually managed to run a task on two cores.. briefly.

Stable material methinks.

On Fri, 2015-12-04 at 03:53 -0800, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  ecf7d01c229d11a44609c0067889372c91fb4f36
> Gitweb:     http://git.kernel.org/tip/ecf7d01c229d11a44609c0067889372c91fb4f36
> Author:     Peter Zijlstra <peterz@infradead.org>
> AuthorDate: Wed, 7 Oct 2015 14:14:13 +0200
> Committer:  Ingo Molnar <mingo@kernel.org>
> CommitDate: Fri, 4 Dec 2015 10:26:43 +0100
> 
> sched/core: Fix an SMP ordering race in try_to_wake_up() vs. schedule()
> 
> Oleg noticed that its possible to falsely observe p->on_cpu == 0 such
> that we'll prematurely continue with the wakeup and effectively run p on
> two CPUs at the same time.
> 
> Even though the overlap is very limited; the task is in the middle of
> being scheduled out; it could still result in corruption of the
> scheduler data structures.
> 
>         CPU0                            CPU1
> 
>         set_current_state(...)
> 
>         
>           context_switch(X, Y)
>             prepare_lock_switch(Y)
>               Y->on_cpu = 1;
>             finish_lock_switch(X)
>               store_release(X->on_cpu, 0);
> 
>                                         try_to_wake_up(X)
>                                           LOCK(p->pi_lock);
> 
>                                           t = X->on_cpu; // 0
> 
>           context_switch(Y, X)
>             prepare_lock_switch(X)
>               X->on_cpu = 1;
>             finish_lock_switch(Y)
>               store_release(Y->on_cpu, 0);
>         
> 
>         schedule();
>           deactivate_task(X);
>           X->on_rq = 0;
> 
>                                           if (X->on_rq) // false
> 
>                                           if (t) while (X->on_cpu)
>                                             cpu_relax();
> 
>           context_switch(X, ..)
>             finish_lock_switch(X)
>               store_release(X->on_cpu, 0);
> 
> Avoid the load of X->on_cpu being hoisted over the X->on_rq load.
> 
> Reported-by: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Mike Galbraith <efault@gmx.de>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
>  kernel/sched/core.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b64f163..7063c6a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1947,6 +1947,25 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
>  
>  #ifdef CONFIG_SMP
>  > 	> /*
> +> 	>  * Ensure we load p->on_cpu _after_ p->on_rq, otherwise it would be
> +> 	>  * possible to, falsely, observe p->on_cpu == 0.
> +> 	>  *
> +> 	>  * One must be running (->on_cpu == 1) in order to remove oneself
> +> 	>  * from the runqueue.
> +> 	>  *
> +> 	>  *  [S] ->on_cpu = 1;> 	> [L] ->on_rq
> +> 	>  *      UNLOCK rq->lock
> +> 	>  *> 	> 	> 	> RMB
> +> 	>  *      LOCK   rq->lock
> +> 	>  *  [S] ->on_rq = 0;    [L] ->on_cpu
> +> 	>  *
> +> 	>  * Pairs with the full barrier implied in the UNLOCK+LOCK on rq->lock
> +> 	>  * from the consecutive calls to schedule(); the first switching to our
> +> 	>  * task, the second putting it to sleep.
> +> 	>  */
> +> 	> smp_rmb();
> +
> +> 	> /*
>  > 	>  * If the owning (remote) cpu is still in the middle of schedule() with
>  > 	>  * this task as prev, wait until its done referencing the task.
>  > 	>  */

^ permalink raw reply	[flat|nested] 4+ messages in thread