mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [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®