From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order Date: Fri, 16 Dec 2016 15:46:53 +0100 Message-ID: <20161216144653.GT3107@twins.programming.kicks-ass.net> References: <1480601214-26583-1-git-send-email-nhaehnle@gmail.com> <1480601214-26583-6-git-send-email-nhaehnle@gmail.com> <20161206165544.GX3045@worktop.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9D1BE6EC21 for ; Fri, 16 Dec 2016 14:47:00 +0000 (UTC) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Nicolai =?iso-8859-1?Q?H=E4hnle?= Cc: Maarten Lankhorst , Nicolai =?iso-8859-1?Q?H=E4hnle?= , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Ingo Molnar List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCBEZWMgMTYsIDIwMTYgYXQgMDM6MTk6NDNQTSArMDEwMCwgTmljb2xhaSBIw6Robmxl IHdyb3RlOgo+IEhpIFBldGVyIGFuZCBDaHJpcywKPiAKPiAodHJ5aW5nIHRvIGNvbWJpbmUgdGhl IGhhbmRvZmYgZGlzY3Vzc2lvbiBoZXJlKQo+IAo+IE9uIDA2LjEyLjIwMTYgMTc6NTUsIFBldGVy IFppamxzdHJhIHdyb3RlOgo+ID5PbiBUaHUsIERlYyAwMSwgMjAxNiBhdCAwMzowNjo0OFBNICsw MTAwLCBOaWNvbGFpIEjDpGhubGUgd3JvdGU6Cj4gPj5AQCAtNjkzLDggKzc0OCwxMiBAQCBfX211 dGV4X2xvY2tfY29tbW9uKHN0cnVjdCBtdXRleCAqbG9jaywgbG9uZyBzdGF0ZSwgdW5zaWduZWQg aW50IHN1YmNsYXNzLAo+ID4+IAkJICogbXV0ZXhfdW5sb2NrKCkgaGFuZGluZyB0aGUgbG9jayBv ZmYgdG8gdXMsIGRvIGEgdHJ5bG9jawo+ID4+IAkJICogYmVmb3JlIHRlc3RpbmcgdGhlIGVycm9y IGNvbmRpdGlvbnMgdG8gbWFrZSBzdXJlIHdlIHBpY2sgdXAKPiA+PiAJCSAqIHRoZSBoYW5kb2Zm Lgo+ID4+KwkJICoKPiA+PisJCSAqIEZvciB3L3cgbG9ja3MsIHdlIGFsd2F5cyBuZWVkIHRvIGRv IHRoaXMgZXZlbiBpZiB3ZSdyZSBub3QKPiA+PisJCSAqIGN1cnJlbnRseSB0aGUgZmlyc3Qgd2Fp dGVyLCBiZWNhdXNlIHdlIG1heSBoYXZlIGJlZW4gdGhlCj4gPj4rCQkgKiBmaXJzdCB3YWl0ZXIg ZHVyaW5nIHRoZSB1bmxvY2suCj4gPj4gCQkgKi8KPiA+Pi0JCWlmIChfX211dGV4X3RyeWxvY2so bG9jaywgZmlyc3QpKQo+ID4+KwkJaWYgKF9fbXV0ZXhfdHJ5bG9jayhsb2NrLCB1c2Vfd3dfY3R4 IHx8IGZpcnN0KSkKPiA+PiAJCQlnb3RvIGFjcXVpcmVkOwo+ID4KPiA+U28gSSdtIHNvbWV3aGF0 IHVuY29tZm9ydGFibGUgd2l0aCB0aGlzLiBUaGUgcG9pbnQgaXMgdGhhdCB3aXRoIHRoZQo+ID4u aGFuZG9mZiBsb2dpYyBpdCBpcyB2ZXJ5IGVhc3kgdG8gYWNjaWRlbnRhbGx5IGFsbG93Ogo+ID4K PiA+CW11dGV4X2xvY2soJmEpOwo+ID4JbXV0ZXhfbG9jaygmYSk7Cj4gPgo+ID5BbmQgSSdtIG5v dCBzdXJlIHRoaXMgZG9lc24ndCBtYWtlIHRoYXQgaGFwcGVuIGZvciB3d19tdXRleGVzLiBXZSBn ZXQgdG8KPiA+dGhpcyBfX211dGV4X3RyeWxvY2soKSB3aXRob3V0IGZpcnN0IGhhdmluZyBibG9j a2VkLgo+IAo+IE9rYXksIHRvb2sgbWUgYSB3aGlsZSwgYnV0IEkgc2VlIHRoZSBwcm9ibGVtLiBJ ZiB3ZSBoYXZlOgo+IAo+IAl3d19tdXRleF9sb2NrKCZhLCBOVUxMKTsKPiAJd3dfbXV0ZXhfbG9j aygmYSwgY3R4KTsKPiAKPiB0aGVuIGl0J3MgcG9zc2libGUgdGhhdCBhbm90aGVyIGN1cnJlbnRs eSB3YWl0aW5nIHRhc2sgc2V0cyB0aGUgSEFORE9GRiBmbGFnCj4gYmV0d2VlbiB0aG9zZSBjYWxs cyBhbmQgd2UnbGwgYWxsb3cgdGhlIHNlY29uZCB3d19tdXRleF9sb2NrIHRvIGdvIHRocm91Z2gu CgpJdHMgd29yc2UsIF9fbXV0ZXhfdHJ5bG9jaygpIGRvZXNuJ3QgY2hlY2sgaWYgTVVURVhfRkxB R19IQU5ET0ZGIGlzIHNldCwKaWYgLmhhbmRvZmYgPT0gdHJ1ZSAmJiBfX293bmVyX3Rhc2soKSA9 PSBjdXJyZW50LCB3ZSAnYWNxdWlyZScuCgpBbmQgc2luY2UgJ3VzZV93d19jdHgnIGlzIHVuY29u ZGl0aW9uYWxseSB0cnVlIGZvciB3d19tdXRleF9sb2NrKCksIHRoZQpzZXF1ZW5jZToKCgl3d19t dXRleF9sb2NrKCZhLCAuLi4pOwoJd3dfbXV0ZXhfbG9jaygmYSwgLi4uKTsKCndpbGwgJ3dvcmsn LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRl dmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8v bGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761979AbcLPQIt (ORCPT ); Fri, 16 Dec 2016 11:08:49 -0500 Received: from merlin.infradead.org ([205.233.59.134]:46798 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754615AbcLPQIl (ORCPT ); Fri, 16 Dec 2016 11:08:41 -0500 Date: Fri, 16 Dec 2016 15:46:53 +0100 From: Peter Zijlstra To: Nicolai =?iso-8859-1?Q?H=E4hnle?= Cc: linux-kernel@vger.kernel.org, Nicolai =?iso-8859-1?Q?H=E4hnle?= , Ingo Molnar , Maarten Lankhorst , Daniel Vetter , Chris Wilson , dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order Message-ID: <20161216144653.GT3107@twins.programming.kicks-ass.net> References: <1480601214-26583-1-git-send-email-nhaehnle@gmail.com> <1480601214-26583-6-git-send-email-nhaehnle@gmail.com> <20161206165544.GX3045@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote: > Hi Peter and Chris, > > (trying to combine the handoff discussion here) > > On 06.12.2016 17:55, Peter Zijlstra wrote: > >On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: > >>@@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, > >> * mutex_unlock() handing the lock off to us, do a trylock > >> * before testing the error conditions to make sure we pick up > >> * the handoff. > >>+ * > >>+ * For w/w locks, we always need to do this even if we're not > >>+ * currently the first waiter, because we may have been the > >>+ * first waiter during the unlock. > >> */ > >>- if (__mutex_trylock(lock, first)) > >>+ if (__mutex_trylock(lock, use_ww_ctx || first)) > >> goto acquired; > > > >So I'm somewhat uncomfortable with this. The point is that with the > >.handoff logic it is very easy to accidentally allow: > > > > mutex_lock(&a); > > mutex_lock(&a); > > > >And I'm not sure this doesn't make that happen for ww_mutexes. We get to > >this __mutex_trylock() without first having blocked. > > Okay, took me a while, but I see the problem. If we have: > > ww_mutex_lock(&a, NULL); > ww_mutex_lock(&a, ctx); > > then it's possible that another currently waiting task sets the HANDOFF flag > between those calls and we'll allow the second ww_mutex_lock to go through. Its worse, __mutex_trylock() doesn't check if MUTEX_FLAG_HANDOFF is set, if .handoff == true && __owner_task() == current, we 'acquire'. And since 'use_ww_ctx' is unconditionally true for ww_mutex_lock(), the sequence: ww_mutex_lock(&a, ...); ww_mutex_lock(&a, ...); will 'work'.