Commit ffd44db5f02af32bcc25a8eb5981bf02a141cdab

Authored by Peter Zijlstra
Committed by Ingo Molnar
1 parent eae0c9dfb5

sched: Make sure task has correct sched_class after policy change

From the code in rt_mutex_setprio(), it is evident that the
intention is that task's with a RT 'prio' value as a consequence
of receiving a PI boost also have their 'sched_class' field set
to '&rt_sched_class'.

However, Peter noticed that the code in __setscheduler() could
result in this intention being frustrated. Fix it.

Reported-by: Peter Williams <pwil3058@bigpond.net.au>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1257880321.4108.457.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Showing 1 changed file with 4 additions and 12 deletions Side-by-side Diff

... ... @@ -6159,22 +6159,14 @@
6159 6159 BUG_ON(p->se.on_rq);
6160 6160  
6161 6161 p->policy = policy;
6162   - switch (p->policy) {
6163   - case SCHED_NORMAL:
6164   - case SCHED_BATCH:
6165   - case SCHED_IDLE:
6166   - p->sched_class = &fair_sched_class;
6167   - break;
6168   - case SCHED_FIFO:
6169   - case SCHED_RR:
6170   - p->sched_class = &rt_sched_class;
6171   - break;
6172   - }
6173   -
6174 6162 p->rt_priority = prio;
6175 6163 p->normal_prio = normal_prio(p);
6176 6164 /* we are holding p->pi_lock already */
6177 6165 p->prio = rt_mutex_getprio(p);
  6166 + if (rt_prio(p->prio))
  6167 + p->sched_class = &rt_sched_class;
  6168 + else
  6169 + p->sched_class = &fair_sched_class;
6178 6170 set_load_weight(p);
6179 6171 }
6180 6172