From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758282AbcHYWYA (ORCPT ); Thu, 25 Aug 2016 18:24:00 -0400 Received: from merlin.infradead.org ([205.233.59.134]:51622 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751033AbcHYWX7 (ORCPT ); Thu, 25 Aug 2016 18:23:59 -0400 Date: Fri, 26 Aug 2016 00:23:28 +0200 From: Peter Zijlstra To: Waiman Long Cc: Linus Torvalds , Jason Low , Ding Tianhong , Thomas Gleixner , Will Deacon , Ingo Molnar , Imre Deak , Linux Kernel Mailing List , Davidlohr Bueso , Tim Chen , Terry Rudd , "Paul E. McKenney" , Jason Low , Chris Wilson , Daniel Vetter Subject: Re: [RFC][PATCH -v2 4/4] locking/mutex: Add lock handoff to avoid starvation Message-ID: <20160825222328.GN10138@twins.programming.kicks-ass.net> References: <20160825183734.113736626@infradead.org> <20160825184324.934871397@infradead.org> <57BF6A73.1050505@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57BF6A73.1050505@hpe.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 25, 2016 at 06:00:19PM -0400, Waiman Long wrote: > On 08/25/2016 02:37 PM, Peter Zijlstra wrote: > >@@ -468,9 +496,12 @@ void __sched mutex_unlock(struct mutex * > > DEBUG_LOCKS_WARN_ON(__mutex_owner(lock) != current); > > #endif > > > >- owner = atomic_long_fetch_and(MUTEX_FLAGS,&lock->owner); > >+ owner = atomic_long_read(&lock->owner); > >+ if (!(owner& MUTEX_FLAG_HANDOFF)) > >+ owner = atomic_long_fetch_and(MUTEX_FLAGS,&lock->owner); > >+ > > if (__owner_flags(owner)) > >- __mutex_unlock_slowpath(lock); > >+ __mutex_unlock_slowpath(lock, owner); > > } > > EXPORT_SYMBOL(mutex_unlock); > > I don't think the race condition is fixed when we don't make sure that lock > handoff only happens from current=>new. The problem is due to the fact that > the MUTEX_FLAG_HANDOFF check in the unlock fastpath isn't serialized by the > wait_lock. As a result, it is possible that the owner is NULL while the > HANDOFF bit is set. Or an optimistic spinner may have stolen the lock in the > interim. You're right.. I'll try again tomorrow.