Received: by 10.223.185.116 with SMTP id b49csp2323071wrg;
        Thu, 22 Feb 2018 11:48:53 -0800 (PST)
X-Google-Smtp-Source: AH8x225p+IwBcKX4WwvsllXWLBf1FyqwTcR7FYm7IxJcJVCicdR7Sbft7HSlxD9TkvrWW1gBicnm
X-Received: by 10.98.171.24 with SMTP id p24mr1191495pff.71.1519328933860;
        Thu, 22 Feb 2018 11:48:53 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1519328933; cv=none;
        d=google.com; s=arc-20160816;
        b=O64U/fJeQH6vPEFXyCk8ruL+HSBcKNp+Y3aayEMnjAuUHyR0ce4rvG1XaweyOI0reO
         AchKwf6zZVP2E6Lm/JQfBIjYsBXQr4+eO63KgedUbu33ipsJI+Wuad+oMhLMgqT8eQGx
         dBghwN7f/O+YR9oSvjbMCLBalQod446Z4VUbCDfPpwu7xX0wGY6Q0V60LbF8GK0hkbfB
         z40ptdxK0WbYQ5LS4erHG6vxrBbK4eyVoYxwCk9mJ09yXAOsdfQhH1J9x/WaBWbahofx
         REMlzu8bTmBjetbLsLSLambCZFKyFNkGXfhY9SrLFDQi5lVqJkvfKb9gDYAmJd13lw7J
         pSYA==
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=n9k6LyPUHoyKT1kismhO6UXNlNt6+SxYzh/kLf3V5Bk=;
        b=wKEKKNlzZ9uZcIkLCJ3RuxCreFoqvdq/rGEofzyluADzj5gHtto7zJpt66Igh6/6hJ
         6X9cuhwEN9ugdTXN8ql9cWD+Lg28LgWNiVvLOSMcmcTamBjuOxbsHnZ0PLdtgbupu5TL
         4Z128fRLnbU7vT/efUKpCXs2QPWV91l9GsUBc1On3dK6mF7wpsIVb9ewVZE+JilpVEN2
         TwaofrbRgzmhqkx1rWdr9SyEgj0OgsYl5qWs5v0eiBD+8vWzmVpNtqNkqso8+8c/fbDL
         VShyUmp7FZvh2wnfs57uFsJ/NjH1Yv59BruQYRqDGu8jR/yd9hRd3+Zn/FEA3P2AcMAS
         6fTQ==
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 e18si491195pfi.130.2018.02.22.11.48.37;
        Thu, 22 Feb 2018 11:48:53 -0800 (PST)
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 S1751387AbeBVTsA (ORCPT <rfc822;c14006078@gmail.com> + 99 others);
        Thu, 22 Feb 2018 14:48:00 -0500
Received: from hqemgate16.nvidia.com ([216.228.121.65]:19607 "EHLO
        hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750967AbeBVTr7 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 22 Feb 2018 14:47:59 -0500
Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com
        id <B5a8f1e720000>; Thu, 22 Feb 2018 11:48:02 -0800
Received: from HQMAIL105.nvidia.com ([172.20.161.6])
  by hqpgpgate102.nvidia.com (PGP Universal service);
  Thu, 22 Feb 2018 11:47:58 -0800
X-PGP-Universal: processed;
        by hqpgpgate102.nvidia.com on Thu, 22 Feb 2018 11:47:58 -0800
Received: from [10.110.39.68] (10.110.39.68) by HQMAIL105.nvidia.com
 (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 22 Feb
 2018 19:47:57 +0000
Subject: Re: [RFC PATCH] riscv/locking: Strengthen spin_lock() and
 spin_unlock()
To:     Peter Zijlstra <peterz@infradead.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
CC:     Andrea Parri <parri.andrea@gmail.com>,
        <linux-kernel@vger.kernel.org>, Palmer Dabbelt <palmer@sifive.com>,
        Albert Ou <albert@sifive.com>,
        Alan Stern <stern@rowland.harvard.edu>,
        Will Deacon <will.deacon@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Nicholas Piggin <npiggin@gmail.com>,
        David Howells <dhowells@redhat.com>,
        Jade Alglave <j.alglave@ucl.ac.uk>,
        Luc Maranget <luc.maranget@inria.fr>,
        Akira Yokosawa <akiyks@gmail.com>,
        Ingo Molnar <mingo@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        <linux-riscv@lists.infradead.org>
References: <1519301990-11766-1-git-send-email-parri.andrea@gmail.com>
 <20180222134004.GN25181@hirez.programming.kicks-ass.net>
 <20180222141249.GA14033@andrea>
 <82beae6a-2589-6136-b563-3946d7c4fc60@nvidia.com>
 <20180222181317.GI2855@linux.vnet.ibm.com>
 <20180222182717.GS25181@hirez.programming.kicks-ass.net>
From:   Daniel Lustig <dlustig@nvidia.com>
Message-ID: <563431d0-4fb5-9efd-c393-83cc5197e934@nvidia.com>
Date:   Thu, 22 Feb 2018 11:47:57 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180222182717.GS25181@hirez.programming.kicks-ass.net>
X-Originating-IP: [10.110.39.68]
X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) 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 2/22/2018 10:27 AM, Peter Zijlstra wrote:
> On Thu, Feb 22, 2018 at 10:13:17AM -0800, Paul E. McKenney wrote:
>> So we have something that is not all that rare in the Linux kernel
>> community, namely two conflicting more-or-less concurrent changes.
>> This clearly needs to be resolved, either by us not strengthening the
>> Linux-kernel memory model in the way we were planning to or by you
>> strengthening RISC-V to be no weaker than PowerPC for these sorts of
>> externally viewed release-acquire situations.
>>
>> Other thoughts?
> 
> Like said in the other email, I would _much_ prefer to not go weaker
> than PPC, I find that PPC is already painfully weak at times.

Sure, and RISC-V could make this work too by using RCsc instructions
and/or by using lightweight fences instead.  It just wasn't clear at
first whether smp_load_acquire() and smp_store_release() were RCpc,
RCsc, or something else, and hence whether RISC-V would actually need
to use something stronger than pure RCpc there.  Likewise for
spin_unlock()/spin_lock() and everywhere else this comes up.

As Paul's email in the other thread observed, RCpc seems to be
OK for smp_load_acquire()/smp_store_release() at least according
to the current LKMM herd spec.  Unlock/lock are stronger already
I guess.  But if there's an active proposal to strengthen them all
to something stricter than pure RCpc, then that's good to know.

My understanding from earlier discussions is that ARM has no plans
to use their own RCpc instruction for smp_load_acquire() instead
of their RCsc instructions.  Is that still true?  If they were to
use the RCpc load there, that would cause them to have the same
problem we're discussing here, right?  Just checking.

Dan