what is the need for task_rq in setscheduler?

[Steven Rostedt]

I'm curious to the need for the task_rq in setscheduler in the following
code:

   3316         rq = task_rq_lock(p, &flags);
   3317         /* recheck policy now with rq lock held */
   3318         if (unlikely(oldpolicy != -1 && oldpolicy != p->policy)) {
   3319                 policy = oldpolicy = -1;
   3320                 task_rq_unlock(rq, &flags);
   3321                 goto recheck;
   3322         }
   3323         array = p->array;
   3324         if (array)
   3325                 deactivate_task(p, task_rq(p));
   3326         retval = 0;
   3327         oldprio = p->prio;
   3328         __setscheduler(p, policy, lp.sched_priority);
   3329         if (array) {
   3330                 __activate_task(p, task_rq(p));
   3331                 /*
   3332                  * Reschedule if we are currently running on this runqueue and
   3333                  * our priority decreased, or if we are not currently running on
   3334                  * this runqueue and our priority is higher than the current's
   3335                  */
   3336                 if (task_running(rq, p)) {
   3337                         if (p->prio > oldprio)
   3338                                 resched_task(rq->curr);
   3339                 } else if (TASK_PREEMPTS_CURR(p, rq))
   3340                         resched_task(rq->curr);
   3341         }
   3342         task_rq_unlock(rq, &flags);


On lines 3325 and 3330 with the calls to deactivate_task and
__activate_task respectively. The runqueue is locked at 3316. Can the
runqueue returned by task_rq change in this setup? If not, what is the
need for the call to task_rq. Can't rq just be used instead, or is this
just some extra paranoia? 

Thanks,

-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/