sched: fix __set_task_cpu() SMP race
authorDmitry Adamushko <dmitry.adamushko@gmail.com>
Thu, 15 Nov 2007 19:57:40 +0000 (20:57 +0100)
committerIngo Molnar <mingo@elte.hu>
Thu, 15 Nov 2007 19:57:40 +0000 (20:57 +0100)
commitce96b5ac742801718ae86d2adf0500c5abef3782
tree1ec0bc7d105af9adc3836a5f47a0f9f62031d14f
parentdae51f56204d33444f61d9e7af3ee70aef55daa4
sched: fix __set_task_cpu() SMP race

Grant Wilson has reported rare SCHED_FAIR_USER crashes on his quad-core
system, which crashes can only be explained via runqueue corruption.

there is a narrow SMP race in __set_task_cpu(): after ->cpu is set up to
a new value, task_rq_lock(p, ...) can be successfuly executed on another
CPU. We must ensure that updates of per-task data have been completed by
this moment.

this bug has been hiding in the Linux scheduler for an eternity (we never
had any explicit barrier for task->cpu in set_task_cpu() - so the bug was
introduced in 2.5.1), but only became visible via set_task_cfs_rq() being
accidentally put after the task->cpu update. It also probably needs a
sufficiently out-of-order CPU to trigger.

Reported-by: Grant Wilson <grant.wilson@zen.co.uk>
Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kernel/sched.c