Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752533AbaBBVMz (ORCPT ); Sun, 2 Feb 2014 16:12:55 -0500 Received: from merlin.infradead.org ([205.233.59.134]:32998 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752455AbaBBVMy (ORCPT ); Sun, 2 Feb 2014 16:12:54 -0500 Date: Sun, 2 Feb 2014 22:12:30 +0100 From: Peter Zijlstra To: Jason Low Cc: Ingo Molnar , Paul McKenney , Waiman Long , Linus Torvalds , Thomas Gleixner , Linux Kernel Mailing List , Rik van Riel , Andrew Morton , Davidlohr Bueso , "H. Peter Anvin" , Andi Kleen , "Chandramouleeswaran, Aswin" , "Norton, Scott J" , chegu_vinod@hp.com Subject: Re: [RFC][PATCH v2 5/5] mutex: Give spinners a chance to spin_on_owner if need_resched() triggered while queued Message-ID: <20140202211230.GX5002@laptop.programming.kicks-ass.net> References: <1390936396-3962-1-git-send-email-jason.low2@hp.com> <1390936396-3962-6-git-send-email-jason.low2@hp.com> <20140128210753.GJ11314@laptop.programming.kicks-ass.net> <1390949495.2807.52.camel@j-VirtualBox> <20140129115142.GE9636@twins.programming.kicks-ass.net> <1391138977.6284.82.camel@j-VirtualBox> <20140131140941.GF4941@twins.programming.kicks-ass.net> <20140131200825.GS5002@laptop.programming.kicks-ass.net> <1391374883.3164.8.camel@j-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1391374883.3164.8.camel@j-VirtualBox> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 02, 2014 at 01:01:23PM -0800, Jason Low wrote: > On Fri, 2014-01-31 at 21:08 +0100, Peter Zijlstra wrote: > > On Fri, Jan 31, 2014 at 12:01:37PM -0800, Jason Low wrote: > > > Currently still getting soft lockups with the updated version. > > > > Bugger.. ok clearly I need to think harder still. I'm fairly sure this > > cancelation can work though, just seems tricky to get right :-) > > Ok, I believe I have found a race condition between m_spin_lock() and > m_spin_unlock(). > > In m_spin_unlock(), we do "next = ACCESS_ONCE(node->next)". Then, if > next is not NULL, we proceed to set next->locked to 1. > > A thread in m_spin_lock() in the unqueue path could execute > "next = cmpxchg(&prev->next, node, NULL)" after the thread in > m_spin_unlock() accesses its node->next and finds that it is not NULL. > Then, the thread in m_spin_lock() could check !node->locked before > the thread in m_spin_unlock() sets next->locked to 1. Yes indeed. How silly of me to not spot that! > The following addition change was able to solve the initial lockups that were > occurring when running fserver on a 2 socket box. > > --- > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c > index 9eb4dbe..e71a84a 100644 > --- a/kernel/locking/mutex.c > +++ b/kernel/locking/mutex.c > @@ -513,8 +513,13 @@ static void m_spin_unlock(struct m_spinlock **lock) > return; > > next = ACCESS_ONCE(node->next); > - if (unlikely(next)) > - break; > + > + if (unlikely(next)) { > + next = cmpxchg(&node->next, next, NULL); > + > + if (next) The cmpxchg could fail and next still be !NULL I suppose. > + break; > + } The way I wrote that same loop in step-B, is: for (;;) { if (*lock == node && cmpxchg(lock, node, prev) == node) return next = xchg(&node->next, NULL); /* B -> A */ if (next) break; arch_mutex_cpu_relax(); } I suppose we can make that something like: if (node->next) { next = xchg(&node->next, NULL); if (next) break } To avoid the xchg on every loop. I had wanted to avoid the additional locked op in the unlock path, but yes that does make things easier. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/