mutex: Fix optimistic spinning vs. BKL
authorTony Breeds <tony@bakeyournoodle.com>
Wed, 19 May 2010 05:46:36 +0000 (15:46 +1000)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 5 Jul 2010 18:10:31 +0000 (11:10 -0700)
commit3aff03b26e6be285ae1b8982a2dc4d4a4c6cb7d5
tree43b2d170f7f165594a19fea8315e428778f36436
parent8b867c02502f86a737e2ec747b0ef15ad93dc6e2
mutex: Fix optimistic spinning vs. BKL

commit fd6be105b883244127a734ac9f14ae94a022dcc0 upstream.

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 <tony@bakeyournoodle.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
LKML-Reference: <20100519054636.GC12389@ozlabs.org>
[ added an unlikely() attribute to the branch ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kernel/mutex.c