diff options
author | Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> | 2007-11-09 22:39:39 +0100 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2007-11-09 22:39:39 +0100 |
commit | 3c90e6e99b08f01d5684a3a07cceae6a543e4fa8 (patch) | |
tree | 2432814cfe4891e4c99945fbe09e6b59d6df49f3 /kernel/sched_fair.c | |
parent | 502d26b524d8980f3ed80d9aec398e85671a8160 (diff) | |
download | linux-3c90e6e99b08f01d5684a3a07cceae6a543e4fa8.tar.gz linux-3c90e6e99b08f01d5684a3a07cceae6a543e4fa8.tar.bz2 linux-3c90e6e99b08f01d5684a3a07cceae6a543e4fa8.zip |
sched: fix copy_namespace() <-> sched_fork() dependency in do_fork
Sukadev Bhattiprolu reported a kernel crash with control groups.
There are couple of problems discovered by Suka's test:
- The test requires the cgroup filesystem to be mounted with
atleast the cpu and ns options (i.e both namespace and cpu
controllers are active in the same hierarchy).
# mkdir /dev/cpuctl
# mount -t cgroup -ocpu,ns none cpuctl
(or simply)
# mount -t cgroup none cpuctl -> Will activate all controllers
in same hierarchy.
- The test invokes clone() with CLONE_NEWNS set. This causes a a new child
to be created, also a new group (do_fork->copy_namespaces->ns_cgroup_clone->
cgroup_clone) and the child is attached to the new group (cgroup_clone->
attach_task->sched_move_task). At this point in time, the child's scheduler
related fields are uninitialized (including its on_rq field, which it has
inherited from parent). As a result sched_move_task thinks its on
runqueue, when it isn't.
As a solution to this problem, I moved sched_fork() call, which
initializes scheduler related fields on a new task, before
copy_namespaces(). I am not sure though whether moving up will
cause other side-effects. Do you see any issue?
- The second problem exposed by this test is that task_new_fair()
assumes that parent and child will be part of the same group (which
needn't be as this test shows). As a result, cfs_rq->curr can be NULL
for the child.
The solution is to test for curr pointer being NULL in
task_new_fair().
With the patch below, I could run ns_exec() fine w/o a crash.
Reported-by: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'kernel/sched_fair.c')
-rw-r--r-- | kernel/sched_fair.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c index 6c361472cc74..d3c03070872d 100644 --- a/kernel/sched_fair.c +++ b/kernel/sched_fair.c @@ -1067,8 +1067,9 @@ static void task_new_fair(struct rq *rq, struct task_struct *p) update_curr(cfs_rq); place_entity(cfs_rq, se, 1); + /* 'curr' will be NULL if the child belongs to a different group */ if (sysctl_sched_child_runs_first && this_cpu == task_cpu(p) && - curr->vruntime < se->vruntime) { + curr && curr->vruntime < se->vruntime) { /* * Upon rescheduling, sched_class::put_prev_task() will place * 'current' within the tree based on its new key value. |