[PATCH] locking/rtmutex: Use EDEADLK for deadlock handling

[Avi Weiss <thnkslprpt@gmail.com>]

rt_mutex_handle_deadlock() checks for -EDEADLOCK, but the rtmutex
deadlock paths return -EDEADLK. These values differ on MIPS,
PowerPC and SPARC, causing the handler to return without entering
the intended warning and scheduling loop.

Compare against -EDEADLK to handle the actual error.

Fixes: 3d5c9340d194 ("rtmutex: Handle deadlock detection smarter")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
---
 kernel/locking/rtmutex.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 5a9534c715b8..e968e88834d8 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1229,7 +1229,7 @@ static int __sched task_blocks_on_rt_mutex(struct rt_mutex_base *lock,
 	 * enqueue on itself just to untangle the mess later. It's not
 	 * only an optimization. We drop the locks, so another waiter
 	 * can come in before the chain walk detects the deadlock. So
-	 * the other will detect the deadlock and return -EDEADLOCK,
+	 * the other will detect the deadlock and return -EDEADLK,
 	 * which is wrong, as the other waiter is not in a deadlock
 	 * situation.
 	 *
@@ -1684,10 +1684,10 @@ static void __sched rt_mutex_handle_deadlock(int res, int detect_deadlock,
 	__must_hold(&lock->wait_lock)
 {
 	/*
-	 * If the result is not -EDEADLOCK or the caller requested
+	 * If the result is not -EDEADLK or the caller requested
 	 * deadlock detection, nothing to do here.
 	 */
-	if (res != -EDEADLOCK || detect_deadlock)
+	if (res != -EDEADLK || detect_deadlock)
 		return;
 
 	if (build_ww_mutex() && w->ww_ctx)

base-commit: 2a500a04d6f969318c05f46aedb6e73fc1963a00
-- 
2.43.0