I suspect I see the bug in that area, but I am not sure it can explain this
trace completely.
Suppose that the SCHED_FIFO task does
switch_uid(new_user);
Now, p->se.cfs_rq and p->se.parent both point into the old user_struct->tg
because sched_move_task() doesn't call set_task_cfs_rq() for !fair_sched_class
case.
Suppose that old user_struct/task_group is freed/reused, and the task does
sched_setscheduler(SCHED_NORMAL);
__setscheduler() sets fair_sched_class, but doesn't update ->se.cfs_rq/parent
which point to the freed memory.
This means that check_preempt_wakeup() doing
while (!is_same_group(se, pse)) {
se = parent_entity(se);
pse = parent_entity(pse);
}
may OOPS in a similar way if rq->curr or p did something like above.
Perhaps we need something like the patch below, note that __setscheduler()
can't do set_task_cfs_rq().
Oleg.
--- kernel/sched.c 2007-11-14 17:32:21.000000000 +0300
+++ - 2007-11-14 18:14:00.245492756 +0300
@@ -7068,8 +7068,10 @@ void sched_move_task(struct task_struct
rq = task_rq_lock(tsk, &flags);
- if (tsk->sched_class != &fair_sched_class)
+ if (tsk->sched_class != &fair_sched_class) {
+ set_task_cfs_rq(tsk);
goto done;
+ }
update_rq_clock(rq);
-
