Commit 02ea9fc9 authored by Peter Zijlstra's avatar Peter Zijlstra
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")
  a055fcc1 ("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) <peterz@infradead.org>
Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20211129174654.668506-4-bigeasy@linutronix.de
parent e08f343b

kernel/locking/rtmutex.c

+4 −1
Original line number Diff line number Diff line
@@ -1103,8 +1103,11 @@ 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)

	if (owner == task && !(build_ww_mutex() && ww_ctx))

		return -EDEADLK;



	raw_spin_lock(&task->pi_lock);