sched: Don't use possibly stale sched_class
authorThomas Gleixner <tglx@linutronix.de>
Wed, 17 Feb 2010 08:05:48 +0000 (09:05 +0100)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 15 Mar 2010 16:07:14 +0000 (09:07 -0700)
commit371f1d177527b1f815b55a03284ccb2c6dc79c3a
tree206f58979b6b9df3a4f0caa473c1b4703bb84fd5
parent51c80d13a1d86848e178a5a5ea31cb0edfeb3efe
sched: Don't use possibly stale sched_class

commit 83ab0aa0d5623d823444db82c3b3c34d7ec364ae upstream.

setscheduler() saves task->sched_class outside of the rq->lock held
region for a check after the setscheduler changes have become
effective. That might result in checking a stale value.

rtmutex_setprio() has the same problem, though it is protected by
p->pi_lock against setscheduler(), but for correctness sake (and to
avoid bad examples) it needs to be fixed as well.

Retrieve task->sched_class inside of the rq->lock held region.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kernel/sched.c