Commit 1e5a5b5e authored Aug 10, 2015 by Riley Andrews Committed by Rishabh Bhatnagar Jul 18, 2018

mutex: Add a delay into the SPIN_ON_OWNER wait loop.



On arm systems the spin on owner optimization can intermittently cause a
lockup that's usually as long as the waiting thread's cpu timeslice. The
repeated mutex aquisitions + atomics in a single spinning thread can
completely lock out the owner from releasing the kernel mutex. The
owner needs to acquire a spinlock on the relase path and this spinlock
can share a monitor with the other locks and atomics on the waiter path.
Rate limit the waiter so that the thread releasing the mutex never
is starved.

Bug 23036902

Change-Id: Ie1b64275a0c6141f94faaf3e63fcbf9b5438140c
Signed-off-by: Riley Andrews <riandrews@google.com>
Git-commit: 84d8ce7e0025cac60a8a379a7ee3e59d640fbc03
Git-repo: https://android.googlesource.com/kernel/msm.git


Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>

parent 13c6da45

kernel/locking/mutex.c

+12 −0

Original line number	Diff line number	Diff line
		@@ -28,6 +28,7 @@
		#include <linux/interrupt.h>
		#include <linux/debug_locks.h>
		#include <linux/osq_lock.h>
		#include <linux/delay.h>

		#ifdef CONFIG_DEBUG_MUTEXES
		# include "mutex-debug.h"
		@@ -555,6 +556,17 @@ mutex_optimistic_spin(struct mutex lock, struct ww_acquire_ctx ww_ctx,
		* values at the cost of a few extra spins.
		*/
		cpu_relax();

		/*
		* On arm systems, we must slow down the waiter's repeated
		* aquisition of spin_mlock and atomics on the lock count, or
		* we risk starving out a thread attempting to release the
		* mutex. The mutex slowpath release must take spin lock
		* wait_lock. This spin lock can share a monitor with the
		* other waiter atomics in the mutex data structure, so must
		* take care to rate limit the waiters.
		*/
		udelay(1);
		}

		if (!waiter)