Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752401AbcDBGja (ORCPT <rfc822;w@1wt.eu>);
	Sat, 2 Apr 2016 02:39:30 -0400
Received: from mx2.suse.de ([195.135.220.15]:50396 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751341AbcDBGj3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 2 Apr 2016 02:39:29 -0400
Date: Fri, 1 Apr 2016 23:39:19 -0700
From: Davidlohr Bueso <dave@stgolabs.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>,
        Petros Koutoupis <petros@petroskoutoupis.com>,
        linux-kernel@vger.kernel.org,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        catalin.marinas@arm.com, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: futex: clarification needed with drop_futex_key_refs and memory
 barriers
Message-ID: <20160402063919.GD5329@linux-uzut.site>
References: <1459007812.5648.5.camel@petros-ultrathin>
 <1459059948.3799.14.camel@gmail.com>
 <20160329095039.GE3408@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20160329095039.GE3408@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1004
Lines: 24

On Tue, 29 Mar 2016, Peter Zijlstra wrote:

>In any case; the below (completely irrelevant patch for you) is
>something I would propose. It gives hb_waiter_dec() RELEASE like
>semantics and ensures it cannot creep into the lock sections its
>typically behind. Although strictly speaking I think it being inside
>that lock region is sufficient.

Indeed, it should be sufficient. Racing with waiter decrements
(leaking into the hb critical region) is perfectly ok as the
consequence is that the reader thread will simply go take the lock
by not seeing the 1->0 dec, and therefore no harm done. Something that
0->1 cannot afford to rely on, obviously. So I think we can save the extra
barrier for the release semantics and keep the call relaxed, as the
performance penalty would be higher. Or are you referring to something else?

>
>It also re-orders the increment in requeue to happen before we add to
>the list (as is the proper order)

ack to this part -- should be a separate patch.

Thanks,
Davidlohr