lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2015-05-05 23:01    [W:0.066 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site