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

From: Avi Weiss

Date: Sat Oct 31 2026 - 01:27:12 EST


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@xxxxxxxxx>
---
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