ff77e46853
Andrea Parri reported:
> I found that the following scenario (with CONFIG_RT_GROUP_SCHED=y) is not
> handled correctly:
>
> T1 (prio = 20)
> lock(rtmutex);
>
> T2 (prio = 20)
> blocks on rtmutex (rt_nr_boosted = 0 on T1's rq)
>
> T1 (prio = 20)
> sys_set_scheduler(prio = 0)
> [new_effective_prio == oldprio]
> T1 prio = 20 (rt_nr_boosted = 0 on T1's rq)
>
> The last step is incorrect as T1 is now boosted (c.f., rt_se_boosted());
> in particular, if we continue with
>
> T1 (prio = 20)
> unlock(rtmutex)
> wakeup(T2)
> adjust_prio(T1)
> [prio != rt_mutex_getprio(T1)]
> dequeue(T1)
> rt_nr_boosted = (unsigned long)(-1)
> ...
> T1 prio = 0
>
> then we end up leaving rt_nr_boosted in an "inconsistent" state.
>
> The simple program attached could reproduce the previous scenario; note
> that, as a consequence of the presence of this state, the "assertion"
>
> WARN_ON(!rt_nr_running && rt_nr_boosted)
>
> from dec_rt_group() may trigger.
So normally we dequeue/enqueue tasks in sched_setscheduler(), which
would ensure the accounting stays correct. However in the early PI path
we fail to do so.
So this was introduced at around v3.14, by:
|
||
---|---|---|
.. | ||
auto_group.c | ||
auto_group.h | ||
clock.c | ||
completion.c | ||
core.c | ||
cpuacct.c | ||
cpuacct.h | ||
cpudeadline.c | ||
cpudeadline.h | ||
cpupri.c | ||
cpupri.h | ||
cputime.c | ||
deadline.c | ||
debug.c | ||
fair.c | ||
features.h | ||
idle_task.c | ||
idle.c | ||
loadavg.c | ||
Makefile | ||
rt.c | ||
sched.h | ||
stats.c | ||
stats.h | ||
stop_task.c | ||
swait.c | ||
wait.c |