Messages in this thread | | | Date | Tue, 5 May 2015 16:20:43 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH V2] sched: Handle priority boosted tasks proper in setscheduler() |
| |
On Tue, 5 May 2015 19:49:49 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
> 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 c365c292d0590 "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> > Fixes: commit c365c292d0590 "sched: Consider pi boosting in setscheduler()" > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Cc: Mike Galbraith <umgwanakikbuti@gmail.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Steven Rostedt <rostedt@goodmis.org> > Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1505051806060.4225@nanos > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Steven Rostedt <rostedt@goodmis.org>
Note, this should be marked stable. I can get a nasty kernel spat with playing around with RT priorities without this patch.
[ 42.226836] ------------[ cut here ]------------ [ 42.227495] WARNING: CPU: 0 PID: 2271 at /home/rostedt/work/git/linux-trace.git/kernel/sched/rt.c:1114 dequeue_rt_stack+0x220/0x22b() [ 42.227495] Modules linked in: [..] [ 42.227495] CPU: 0 PID: 2271 Comm: check_pi_deboos Not tainted 4.1.0-rc1-test+ #415 [ 42.227495] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 [ 42.227495] 0000000000000009 ffff880078a5fd28 ffffffff815fcc4c 0000000080000002 [ 42.227495] 0000000000000000 ffff880078a5fd68 ffffffff810496ea 0000000000000000 [ 42.227495] ffffffff81075d5a ffff88007669e208 ffff88007d416460 0000000000000054 [ 42.227495] Call Trace: [ 42.227495] [<ffffffff815fcc4c>] dump_stack+0x4f/0x7b [ 42.227495] [<ffffffff810496ea>] warn_slowpath_common+0xa1/0xbb [ 42.227495] [<ffffffff81075d5a>] ? dequeue_rt_stack+0x220/0x22b [ 42.227495] [<ffffffff810497a7>] warn_slowpath_null+0x1a/0x1c [ 42.227495] [<ffffffff81075d5a>] dequeue_rt_stack+0x220/0x22b [ 42.227495] [<ffffffff810762dc>] dequeue_rt_entity+0x1f/0x58 [ 42.227495] [<ffffffff810767a1>] dequeue_task_rt+0x24/0x34 [ 42.227495] [<ffffffff81068f03>] dequeue_task+0x69/0x70 [ 42.227495] [<ffffffff8106dfd7>] sched_move_task+0x4e/0xdb [ 42.227495] [<ffffffff8106e07b>] cpu_cgroup_exit+0x17/0x19 [ 42.227495] [<ffffffff810b8065>] cgroup_exit+0x9f/0xbe [ 42.227495] [<ffffffff8104abc7>] do_exit+0x429/0x92f [ 42.227495] [<ffffffff8104bdb1>] SyS_exit+0x17/0x17 [ 42.227495] [<ffffffff81604c97>] system_call_fastpath+0x12/0x6a [ 42.227495] ---[ end trace 14460ffaa77bf181 ]--- [ 42.412352] ------------[ cut here ]------------
-- Steve
| |