Commit 7be88aa5 authored by Peter Zijlstra's avatar Peter Zijlstra Committed by Sebastian Andrzej Siewior
Browse files

locking/rtmutex: Squash self-deadlock check for ww_rt_mutex.

Similar to the issues in commits:

  6467822b ("locking/rtmutex: Prevent spurious EDEADLK return caused by ww_mutexes")

 ("locking/rtmutex: Return success on deadlock for ww_mutex waiters")

ww_rt_mutex_lock() should not return EDEADLK without first going through
the __ww_mutex logic to set the required state. In fact, the chain-walk
can deal with the spurious cycles (per the above commits) this check
warns about and is trying to avoid.

Therefore ignore this test for ww_rt_mutex and simply let things fall
in place.
Signed-off-by: default avatarPeter Zijlstra (Intel) <>
Signed-off-by: default avatarSebastian Andrzej Siewior <>
parent d9136b64
......@@ -1103,27 +1103,12 @@ static int __sched task_blocks_on_rt_mutex(struct rt_mutex_base *lock,
* the other will detect the deadlock and return -EDEADLOCK,
* which is wrong, as the other waiter is not in a deadlock
* situation.
* Except for ww_mutex, in that case the chain walk must already deal
* with spurious cycles, see the comments at [3] and [6].
if (owner == task) {
* The lockdep selftest for ww-mutex assumes in a few cases
* the ww_ctx->contending_lock assignment via
* __ww_mutex_check_kill() which does not happen if the rtmutex
* detects the deadlock early.
if (build_ww_mutex() && ww_ctx) {
struct rt_mutex *rtm;
/* Check whether the waiter should backout immediately */
rtm = container_of(lock, struct rt_mutex, rtmutex);
__ww_mutex_add_waiter(waiter, rtm, ww_ctx);
__ww_mutex_check_kill(rtm, waiter, ww_ctx);
if (owner == task && !(build_ww_mutex() && ww_ctx))
return -EDEADLK;
waiter->task = task;
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment