Received: by 10.223.164.202 with SMTP id h10csp1211198wrb; Wed, 15 Nov 2017 15:20:26 -0800 (PST) X-Google-Smtp-Source: AGs4zMZ3AXAnn/zENfiVFrkUbG7CwNTqANbl4p5jOVn47fN0XjrsAxK+hdHUrRwro/L4w06j6wv/ X-Received: by 10.84.241.15 with SMTP id a15mr11217805pll.103.1510788026449; Wed, 15 Nov 2017 15:20:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510788026; cv=none; d=google.com; s=arc-20160816; b=nwNLUJVHJ24IT8vtpqKOKcNK4UT2MRNWbblH7EltgsUK2F/prD7QnTJ4Fzok4zEcPZ zuc4pZiAwPKOBFouby/z1E8hcsVubZhQLJQFqTh60p1YC3vHF2PyyLEox32vCqB7RYWT K6g0j2YulXHtC9m/KOE32xKFxiE/EWoqCrssKXkLotVX3Z1QphN9wFHx0HAKwCaYmetp JqRZma5GZoqcpQow4jCD0mGz4F1j+DW41Ae8C7uOfpVz3iDHHEL/JtVv45Gc7HWD4F3t 7v6nejGbgHx5G26aMqUjl30BPpLxGEmyOR1w+yHluNYSQudk8zAL2HU1GrSif3aiY6HR z2Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=v2s+mjw6VX6rqL1GYlfjZrgq/6wfT/Nhy7XmGknOf9o=; b=lh9sKTsTBQEfsQCtlCqfie0JkxZ3mSTKalqh5I5Hp9pHD3RwUulqdxm+N1izn0kgqz EBtrv1Sv10IVnMWyy60/M92xnYdocJGzZahninxak4lCxfPWw+DobxufzYktaNm7CBsj XdZGDK8jBZKBssdDzWQpI/YI/0iDAoYg+3KFjHp8L/cNWrs0YOjDbU+w+Q8KuxZsPrqh +ELO3GJBgz1/RXqLwvwTrmqNd2WNn+YphY+Ku2jeCUEKp26/MPlT5IhviERf1pEjrtAQ lXr8rc6O/GFkFQ4Kp51Kh6oA7ereDBLLYW6psuzchvkceUpbBo50yDi0EYiKZmtUZvLn q+CQ== 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=harvard.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si19233134plm.520.2017.11.15.15.20.14; Wed, 15 Nov 2017 15:20:26 -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=harvard.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932972AbdKOTP1 (ORCPT + 89 others); Wed, 15 Nov 2017 14:15:27 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:33304 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1757723AbdKOTPU (ORCPT ); Wed, 15 Nov 2017 14:15:20 -0500 Received: (qmail 3061 invoked by uid 2102); 15 Nov 2017 14:15:19 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Nov 2017 14:15:19 -0500 Date: Wed, 15 Nov 2017 14:15:19 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Will Deacon cc: Peter Zijlstra , "Reshetova, Elena" , "linux-kernel@vger.kernel.org" , "gregkh@linuxfoundation.org" , "keescook@chromium.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "ishkamiel@gmail.com" , Paul McKenney , , , , Subject: Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t In-Reply-To: <20171115180540.GQ19071@arm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 Nov 2017, Will Deacon wrote: > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote: > > I was trying to think of something completely different. If you have a > > release/acquire to the same address, it creates a happens-before > > ordering: > > > > Access x > > Release a > > Acquire a > > Access y > > > > Here is the access to x happens-before the access to y. This is true > > even on x86, even in the presence of forwarding -- the CPU still has to > > execute the instructions in order. But if the release and acquire are > > to different addresses: > > > > Access x > > Release a > > Acquire b > > Access y > > > > then there is no happens-before ordering for x and y -- the CPU can > > execute the last two instructions before the first two. x86 and > > PowerPC won't do this, but I believe ARMv8 can. (Please correct me if > > it can't.) > > Release/Acquire are RCsc on ARMv8, so they are ordered irrespective of > address. Ah, okay, thanks. In any case, we have considered removing this ordering constraint (store-release followed by load-acquire for the same location) from the Linux-kernel memory model. I'm not aware of any code in the kernel that depends on it. Do any of you happen to know of any examples? Alan From 1584169826005434379@xxx Wed Nov 15 21:41:15 +0000 2017 X-GM-THRID: 1582046402032606032 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread