summaryrefslogtreecommitdiffstats
path: root/kernel/locking/rtmutex-debug.c
diff options
context:
space:
mode:
authorPeter Zijlstra <peterz@infradead.org>2017-03-23 15:56:11 +0100
committerThomas Gleixner <tglx@linutronix.de>2017-04-04 11:44:06 +0200
commitacd58620e415aee4a43a808d7d2fd87259ee0001 (patch)
treeb0971a53edac32523a6b99b4bd5f15200041634e /kernel/locking/rtmutex-debug.c
parentaa2bfe55366552cb7e93e8709d66e698d79ccc47 (diff)
downloadblackbird-op-linux-acd58620e415aee4a43a808d7d2fd87259ee0001.tar.gz
blackbird-op-linux-acd58620e415aee4a43a808d7d2fd87259ee0001.zip
sched/rtmutex: Refactor rt_mutex_setprio()
With the introduction of SCHED_DEADLINE the whole notion that priority is a single number is gone, therefore the @prio argument to rt_mutex_setprio() doesn't make sense anymore. So rework the code to pass a pi_task instead. Note this also fixes a problem with pi_top_task caching; previously we would not set the pointer (call rt_mutex_update_top_task) if the priority didn't change, this could lead to a stale pointer. As for the XXX, I think its fine to use pi_task->prio, because if it differs from waiter->prio, a PI chain update is immenent. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: bristot@redhat.com Link: http://lkml.kernel.org/r/20170323150216.303827095@infradead.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'kernel/locking/rtmutex-debug.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud