* [PATCH] locking/rtmutex: Use EDEADLK for deadlock handling
@ 2026-10-31 5:26 Avi Weiss
0 siblings, 0 replies; only message in thread
From: Avi Weiss @ 2026-10-31 5:26 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar
Cc: Will Deacon, Boqun Feng, Waiman Long, Thomas Gleixner, linux-kernel
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-10-31 5:27 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-31 5:26 [PATCH] locking/rtmutex: Use EDEADLK for deadlock handling Avi Weiss
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®