Re: [ 10/65] ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+
From: Will Deacon <hidden>
Date: 2012-08-15 09:10:58
Hi Ben, On Wed, Aug 15, 2012 at 05:29:26AM +0100, Ben Hutchings wrote:
On Mon, 2012-08-13 at 15:13 -0700, Greg Kroah-Hartman wrote:quoted
From: Greg KH <gregkh@linuxfoundation.org> 3.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Will Deacon <redacted> commit a76d7bd96d65fa5119adba97e1b58d95f2e78829 upstream. The open-coded mutex implementation for ARMv6+ cores suffers from a severe lack of barriers, so in the uncontended case we don't actually protect any accesses performed during the critical section. Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec code but optimised to remove a branch instruction, as the mutex fastpath was previously inlined. Now that this is executed out-of-line, we can reuse the atomic access code for the locking (in fact, we use the xchg code as this produces shorter critical sections). This patch uses the generic xchg based implementation for mutexes on ARMv6+, which introduces barriers to the lock/unlock operations and also has the benefit of removing a fair amount of inline assembly code.[...] I understand that a further fix is needed on top of this <http://article.gmane.org/gmane.linux.ports.arm.kernel/181693> but it's not in Linus's tree yet. Is it better to apply this on its own or to wait for the complete fix?
The additional patch should also be CC'd to stable and is sitting in -tip somewhere I believe, so it shouldn't be long before it does hit mainline. Without this patch there's a memory-ordering bug (which we seem to have hit once in > 5 years). With the patch there's a mutex lockup issue on SMP systems that I can provoke with enough hackbenching, so you may want to hold off for now. Will