Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1090380imm;
        Wed, 11 Jul 2018 17:08:14 -0700 (PDT)
X-Google-Smtp-Source: AAOMgpd/2oaxPCS091gukk0NbvwgoSB8by0p5xg0tGxOhGu6Oqasdyj+BVLMdb993m3vMCmOtRW1
X-Received: by 2002:a17:902:599b:: with SMTP id p27-v6mr633612pli.191.1531354094367;
        Wed, 11 Jul 2018 17:08:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1531354094; cv=none;
        d=google.com; s=arc-20160816;
        b=fB29xMxt9CQipGwB11RlTKWXhQTOGGw2u0a8D9eGgJ843+lPQY9omaMdH2TCUWc6IY
         /Z2QUJToK8cLSm2WcJX40lRjGoDzlupZ+ZxDUlor/ZZ01VSalqJiN0ROUOBTqV04yfP3
         b1Jro/AkHSYoVxivji7DkJEIBzUnGgbsorjkW4dSZLwKNfWV18/9M+QyFvT+YNTTmmOI
         9hhMTroq7yZVFWuU/3MT4lPWejymOAVa8Y+HVKXHRreZt5UiD0GjQ4vQOA+boXZbgo3P
         il9hoswgo9zrzVoli9b3UIl0yG8nTR1dq56UajSamiPW4mtca+K4/cYQMtTCV8f0b1ki
         w5JA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:sender:content-transfer-encoding
         :content-language:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:cc:to:subject:arc-authentication-results;
        bh=GLuPrEKVet6Y+fHnc8UquQrhCLsPCHPVbmF8gw+noNo=;
        b=QWssioz0aAfe0RZLn6GMZIwyi4OHx4IhaDzz+Pk0bnJBpkdzPUHZWpXt8NXeef4lNK
         GfcVRP9zUEVTlOsAVU4Zg02hjRGKDiM2UQJoIg6TZx1Rw3F/dxw9K5j45R4LoO/iyLOU
         EXTeJl7cD7UrnWXOan8/EVSQNGGgdmfKpJLS7DlkOrT3TTpq9y5Qv26Cyto97NUwWDdg
         4cDW8LVA7+ym9iqT9V2HeK2McchrJhVdRq1BOgIlnwXL7bUH16lu0qPz/WpFACHc3QtJ
         KMFXTCVTMtd2DepWHvl6dwNMrwfAGC6krYe3Wb/YQhvd0n+5gWG6gqwx4xfYc/4tZJLN
         9H9A==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
        by mx.google.com with ESMTP id g1-v6si20556023pld.11.2018.07.11.17.07.59;
        Wed, 11 Jul 2018 17:08:14 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2389116AbeGKR4X (ORCPT <rfc822;jimmypw@gmail.com> + 99 others);
        Wed, 11 Jul 2018 13:56:23 -0400
Received: from hqemgate14.nvidia.com ([216.228.121.143]:19296 "EHLO
        hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1732456AbeGKR4X (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 11 Jul 2018 13:56:23 -0400
Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1, AES128-SHA)
        id <B5b46437e0001>; Wed, 11 Jul 2018 10:50:55 -0700
Received: from HQMAIL105.nvidia.com ([172.20.161.6])
  by hqpgpgate101.nvidia.com (PGP Universal service);
  Wed, 11 Jul 2018 10:50:57 -0700
X-PGP-Universal: processed;
        by hqpgpgate101.nvidia.com on Wed, 11 Jul 2018 10:50:57 -0700
Received: from [10.110.39.62] (10.110.39.62) by HQMAIL105.nvidia.com
 (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Jul
 2018 17:50:57 +0000
Subject: Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and
 remove it for ordinary release/acquire
To:     Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will.deacon@arm.com>
CC:     Andrea Parri <andrea.parri@amarulasolutions.com>,
        Alan Stern <stern@rowland.harvard.edu>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        David Howells <dhowells@redhat.com>,
        Jade Alglave <j.alglave@ucl.ac.uk>,
        Luc Maranget <luc.maranget@inria.fr>,
        Nicholas Piggin <npiggin@gmail.com>,
        Kernel development list <linux-kernel@vger.kernel.org>
References: <Pine.LNX.4.44L0.1807091519180.2462-100000@iolanthe.rowland.org>
 <20180710093821.GA5414@andrea> <20180711094310.GA13963@arm.com>
 <20180711123421.GA9673@andrea> <20180711155751.GC18477@arm.com>
 <20180711170053.GM2476@hirez.programming.kicks-ass.net>
From:   Daniel Lustig <dlustig@nvidia.com>
Message-ID: <e5148058-c551-ca65-eef3-4259badecf57@nvidia.com>
Date:   Wed, 11 Jul 2018 10:50:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <20180711170053.GM2476@hirez.programming.kicks-ass.net>
X-Originating-IP: [10.110.39.62]
X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To
 HQMAIL105.nvidia.com (172.20.187.12)
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 7/11/2018 10:00 AM, Peter Zijlstra wrote:
> On Wed, Jul 11, 2018 at 04:57:51PM +0100, Will Deacon wrote:
> 
>> It might be simple to model, but I worry this weakens our locking
>> implementations to a point where they will not be understood by the average
>> kernel developer. As I've said before, I would prefer "full" RCsc locking,
> 
> Another vote for RCsc locks. The (in)famous hold-out is of course
> PowerPC, but it now looks like RISC-V is following where they I really
> rather wish they didn't.

That's not entirely fair.  We came in wanting to do the "natural" or
"expected" thing: use RCsc atomics where we have them available in the
ISA, and use "fence r,rw" and "fence rw,w" where we don't.

I would argue that the idea of having data races on variables that are
also protected by locks is equally if not more counterintuitive and
unexpected than the "natural" mapping we had originally proposed to use.

All the discussion here[1] for example is about having ordering and
doing an smp_cond_load_acquire() on a variable which is sometimes
protected by a CPU's rq->lock and sometimes not?  Isn't that one of the
key use cases for this whole discussion?

FWIW, this code also mixes locking, smp_rmb(), and
smp_cond_load_acquire() all in very close proximity with each other...
I suppose there's no mixing and matching on the same variable, but
we are here trying to reason about how all those pieces interact, no?

[1] https://lkml.org/lkml/2015/10/6/805

Dan