Re: [PATCH V2] sched: Handle priority boosted tasks proper in setscheduler()

[Steven Rostedt]

On Tue, 5 May 2015 19:49:49 +0200 (CEST)
Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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@xxxxxxxxx>
> Fixes: commit c365c292d0590 "sched: Consider pi boosting in setscheduler()"
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: Mike Galbraith <umgwanakikbuti@xxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>
> Link: alpine.DEB.2.11.1505051806060.4225@nanos">http://lkml.kernel.org/r/alpine.DEB.2.11.1505051806060.4225@nanos
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>

Reviewed-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
Tested-by: Steven Rostedt <rostedt@xxxxxxxxxxx>

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

--
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/