sched: Fix TASK_WAKING vs fork deadlock
authorPeter Zijlstra <a.p.zijlstra@chello.nl>
Wed, 24 Mar 2010 17:34:10 +0000 (18:34 +0100)
committerIngo Molnar <mingo@elte.hu>
Fri, 2 Apr 2010 18:12:03 +0000 (20:12 +0200)
commit0017d735092844118bef006696a750a0e4ef6ebd
tree8ed1540aaeb63da726f93da12950a8eaa0e0a3e0
parent9084bb8246ea935b98320554229e2f371f7f52fa
sched: Fix TASK_WAKING vs fork deadlock

Oleg noticed a few races with the TASK_WAKING usage on fork.

 - since TASK_WAKING is basically a spinlock, it should be IRQ safe
 - since we set TASK_WAKING (*) without holding rq->lock it could
   be there still is a rq->lock holder, thereby not actually
   providing full serialization.

(*) in fact we clear PF_STARTING, which in effect enables TASK_WAKING.

Cure the second issue by not setting TASK_WAKING in sched_fork(), but
only temporarily in wake_up_new_task() while calling select_task_rq().

Cure the first by holding rq->lock around the select_task_rq() call,
this will disable IRQs, this however requires that we push down the
rq->lock release into select_task_rq_fair()'s cgroup stuff.

Because select_task_rq_fair() still needs to drop the rq->lock we
cannot fully get rid of TASK_WAKING.

Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
include/linux/sched.h
kernel/sched.c
kernel/sched_fair.c
kernel/sched_idletask.c
kernel/sched_rt.c