Thomas Gleixner 0782e63bc6 sched: Handle priority boosted tasks proper in setscheduler() ... Ronny reported that the following scenario is not handled correctly: T1 (prio = 10) lock(rtmutex); T2 (prio = 20) lock(rtmutex) boost T1 T1 (prio = 20) sys_set_scheduler(prio = 30) T1 prio = 30 .... sys_set_scheduler(prio = 10) T1 prio = 30 The last step is wrong as T1 should now be back at prio 20. Commit c365c292d0 ("sched: Consider pi boosting in setscheduler()") only handles the case where a boosted tasks tries to lower its priority. Fix it by taking the new effective priority into account for the decision whether a change of the priority is required. Reported-by: Ronny Meeus <ronny.meeus@gmail.com> Tested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Mike Galbraith <umgwanakikbuti@gmail.com> Fixes: c365c292d0 ("sched: Consider pi boosting in setscheduler()") Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1505051806060.4225@nanos Signed-off-by: Ingo Molnar <mingo@kernel.org>		2015-05-08 11:53:55 +02:00
..
lglock.c
lockdep_internals.h
lockdep_proc.c
lockdep_states.h
lockdep.c	lockdep: Make print_lock() robust against concurrent release	2015-04-17 09:42:14 +02:00
locktorture.c
Makefile
mcs_spinlock.h
mutex-debug.c
mutex-debug.h
mutex.c	locking/mutex: Further simplify mutex_spin_on_owner()	2015-04-09 08:10:23 +02:00
mutex.h
osq_lock.c
percpu-rwsem.c
qrwlock.c
rtmutex_common.h
rtmutex-debug.c
rtmutex-debug.h
rtmutex-tester.c
rtmutex.c	sched: Handle priority boosted tasks proper in setscheduler()	2015-05-08 11:53:55 +02:00
rtmutex.h
rwsem-spinlock.c
rwsem-xadd.c	locking/rwsem: Fix lock optimistic spinning when owner is not running	2015-03-07 09:50:49 +01:00
rwsem.c
rwsem.h
semaphore.c
spinlock_debug.c
spinlock.c