From: Tony Breeds Date: Wed, 19 May 2010 05:46:36 +0000 (+1000) Subject: mutex: Fix optimistic spinning vs. BKL X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=fd6be105b883244127a734ac9f14ae94a022dcc0;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git mutex: Fix optimistic spinning vs. BKL Currently, we can hit a nasty case with optimistic spinning on mutexes: CPU A tries to take a mutex, while holding the BKL CPU B tried to take the BLK while holding the mutex This looks like a AB-BA scenario but in practice, is allowed and happens due to the auto-release on schedule() nature of the BKL. In that case, the optimistic spinning code can get us into a situation where instead of going to sleep, A will spin waiting for B who is spinning waiting for A, and the only way out of that loop is the need_resched() test in mutex_spin_on_owner(). This patch fixes it by completely disabling spinning if we own the BKL. This adds one more detail to the extensive list of reasons why it's a bad idea for kernel code to be holding the BKL. Signed-off-by: Tony Breeds Acked-by: Linus Torvalds Acked-by: Peter Zijlstra Cc: Benjamin Herrenschmidt Cc: LKML-Reference: <20100519054636.GC12389@ozlabs.org> [ added an unlikely() attribute to the branch ] Signed-off-by: Ingo Molnar --- diff --git a/kernel/mutex.c b/kernel/mutex.c index 632f04c57d82..4c0b7b3e6d2e 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -171,6 +171,13 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, for (;;) { struct thread_info *owner; + /* + * If we own the BKL, then don't spin. The owner of + * the mutex might be waiting on us to release the BKL. + */ + if (unlikely(current->lock_depth >= 0)) + break; + /* * If there's an owner, wait for it to either * release the lock or go to sleep.