Received: by 10.223.185.116 with SMTP id b49csp1399312wrg; Fri, 16 Feb 2018 19:26:37 -0800 (PST) X-Google-Smtp-Source: AH8x2278Lxrgg6JiQ95gNAq2dtZbRQIyOVC/YiFJq/3DbNGnu0yXhTVNvthfz7KzfY09BUhWASYz X-Received: by 2002:a17:902:6b89:: with SMTP id p9-v6mr7798096plk.377.1518837997685; Fri, 16 Feb 2018 19:26:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518837997; cv=none; d=google.com; s=arc-20160816; b=OMbpPvXAf2tmJMZ2VisnC4amBEgM+Fr99QjRMF0AhTzERW88R1Ipz3J9Vh4rER0iIZ J+03kY7BvvW6g0W7Hiu+Ht1jofPalHtVshruhKvRjjm+1M+DnMk5On9SRBDf9YCo+iL+ wLSfA+2qyd0LwxVZFTeTiRInldjnDbuzBonT8haLoujidBUo76C21S/2OkBgyGKZu6NU /JLHkydecv4m7cQ+Outl3IufYcrw7ms8KOoOdrUZXUDcqUwrbHS/Me06Olgf2ZjMHKHE Q7xluvXeAsmrt83cPGqhmSKtyVohkqMNqgSnjCV4gE+FX0gLhz/ppgyHSJpuizy18Qrr ZRQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=2sPcgZ9qsQCsxUow9ad57kV9kYMzSXA9vicDra+4Nc0=; b=PiHGvx7kJAyvaArZ+lTAzH9StMJDrqPN3SOvQHTyczaxJqoU7IYnbsXKQxLN5Vm3kF TTvO3uO9cTya3jQLiAgTN+UkLEKAI4NcNQtMsZmh1vaGnO1Vy21+yNf3dxTm1vYPBVwq uR9X22y2XMS3YNn1JX5PuCgIS8a6HRwc4rruuJZCRrkmnD/69Mn7BcqztnXPa5yINXvw JXJZfelHNjmhm1NKRYpD3RflTWgAjFTbemnQOSPmJHW92oqlqt+JqlbhQA+BvNceVIji ZMx9lg1CpGohab8/SG26kXl4RozPH1eW1ymgUDbLd3hgQezX/BdiOEQgb/wo5lqgPi7r jdVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tD0GT5Lx; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2si428161pfm.409.2018.02.16.19.26.23; Fri, 16 Feb 2018 19:26:37 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tD0GT5Lx; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751054AbeBQDZp (ORCPT + 99 others); Fri, 16 Feb 2018 22:25:45 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:53321 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750763AbeBQDZo (ORCPT ); Fri, 16 Feb 2018 22:25:44 -0500 Received: by mail-wm0-f68.google.com with SMTP id t74so6263798wme.3 for ; Fri, 16 Feb 2018 19:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2sPcgZ9qsQCsxUow9ad57kV9kYMzSXA9vicDra+4Nc0=; b=tD0GT5LxU69X+ctLsh4y+2hbxhOK3KqhYBwregaUkRCB+5pVGR8ZUUmf6EsVQ6MxQD 3RXHA3ONxle8wUvPS40VLqJEuxOx2WDac+B8jVydFzcf/C1vV+HzhfdbSHC66l32KQ5E sFsOvHj3jjeJr/rm/F/ztGr6wNscVezfRKw0o1Ur7iKM79i7ZEj1gnJa6QCdZ959OAOX uulosL0JEKCwrAMIhhK3tIfjRhWHcF4fc1d9Q1MeNrldwQ9/5lUh7D5PAVEoDQMOosjH ue1/6zrpLOGcs33JjTES6DdAA+dJeZSgYwcuRXjzzC0Elu7iwMsaH2W9n7P9yVF6hLO0 xq7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2sPcgZ9qsQCsxUow9ad57kV9kYMzSXA9vicDra+4Nc0=; b=HcOsHcOcihmH8WfMU9j+MmsUxgAqG4SodTDnVrQ0S9Nc7XWHLOXER+7RlSkHP1rTXY QcGc6NUgpP5NzEo323VfwxIn7XudGSeDvoUEeHFXT6LsMco4MK2GuHO7xXh6iV+QK7zm lUSeLLhuW7HQr6dk9kv4RgRrcu4DMizJb6OklkmVhc4/Moufo7+9Kanpnu2amEr1tEaE y/Z7d2+zxv14lS79I93BMPryUp2OgF+W8G933dQ4hWHXK0W+X3mK3q5hFxqAkJLYBuqh SORlZJwWksOSNOUESQ6tql3xXhSW8c9AP43skYtEvBv2uQjrRyrYlIAqcjDzrll0Zo+U Jfjw== X-Gm-Message-State: APf1xPCS1pHDG6L935LR4uAwfkZ3jmLXAepU9jkFzDUL/dxY9vbvqf1d xFx8Xm6AmeKYVUF9+XYKecY= X-Received: by 10.80.181.50 with SMTP id y47mr5079981edd.29.1518837943090; Fri, 16 Feb 2018 19:25:43 -0800 (PST) Received: from andrea (dynamic-2a00-1028-8386-da8a-c851-684e-0b46-8600.ipv6.broadband.iol.cz. [2a00:1028:8386:da8a:c851:684e:b46:8600]) by smtp.gmail.com with ESMTPSA id c58sm4087264edb.33.2018.02.16.19.25.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 19:25:42 -0800 (PST) Date: Sat, 17 Feb 2018 04:25:35 +0100 From: Andrea Parri To: Alan Stern Cc: "Paul E. McKenney" , Akira Yokosawa , Kernel development list , mingo@kernel.org, Will Deacon , peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, Jade Alglave , Luc Maranget , Patrick Bellasi Subject: Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference Message-ID: <20180217032535.GA1125@andrea> References: <20180216165301.GF3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 16, 2018 at 05:22:55PM -0500, Alan Stern wrote: > Since commit 76ebbe78f739 ("locking/barriers: Add implicit > smp_read_barrier_depends() to READ_ONCE()") was merged for the 4.15 > kernel, it has not been necessary to use smp_read_barrier_depends(). > Similarly, commit 59ecbbe7b31c ("locking/barriers: Kill > lockless_dereference()") removed lockless_dereference() from the > kernel. > > Since these primitives are no longer part of the kernel, they do not > belong in the Linux Kernel Memory Consistency Model. This patch > removes them, along with the internal rb-dep relation, and updates the > revelant documentation. > > Signed-off-by: Alan Stern > > --- [...] > Index: usb-4.x/tools/memory-model/linux-kernel.def > =================================================================== > --- usb-4.x/tools/memory-model.orig/linux-kernel.def > +++ usb-4.x/tools/memory-model/linux-kernel.def > @@ -13,14 +13,12 @@ WRITE_ONCE(X,V) { __store{once}(X,V); } > smp_store_release(X,V) { __store{release}(*X,V); } > smp_load_acquire(X) __load{acquire}(*X) > rcu_assign_pointer(X,V) { __store{release}(X,V); } > -lockless_dereference(X) __load{lderef}(X) > rcu_dereference(X) __load{deref}(X) ^^^ __load{once} > > // Fences > smp_mb() { __fence{mb} ; } > smp_rmb() { __fence{rmb} ; } > smp_wmb() { __fence{wmb} ; } > -smp_read_barrier_depends() { __fence{rb_dep}; } > smp_mb__before_atomic() { __fence{before-atomic} ; } > smp_mb__after_atomic() { __fence{after-atomic} ; } > smp_mb__after_spinlock() { __fence{after-spinlock} ; } > Index: usb-4.x/tools/memory-model/Documentation/cheatsheet.txt > =================================================================== > --- usb-4.x/tools/memory-model.orig/Documentation/cheatsheet.txt > +++ usb-4.x/tools/memory-model/Documentation/cheatsheet.txt > @@ -6,8 +6,7 @@ > Store, e.g., WRITE_ONCE() Y Y > Load, e.g., READ_ONCE() Y Y Y > Unsuccessful RMW operation Y Y Y > -smp_read_barrier_depends() Y Y Y > -*_dereference() Y Y Y Y > +rcu_dereference() Y Y Y Y > Successful *_acquire() R Y Y Y Y Y Y > Successful *_release() C Y Y Y W Y > smp_rmb() Y R Y Y R Akira's observation about READ_ONCE extends to all (annotated) loads. In fact, it also applies to loads corresponding to unsuccessful RMW operations; consider, for example, the following variation of MP+onceassign+derefonce: C T { y=z; z=0; } P0(int *x, int **y) { WRITE_ONCE(*x, 1); smp_store_release(y, x); } P1(int **y, int *z) { int *r0; int r1; r0 = cmpxchg_relaxed(y, z, z); r1 = READ_ONCE(*r0); } exists (1:r0=x /\ 1:r1=0) The final state is allowed w/o the patch, and forbidden w/ the patch. This also reminds me of 5a8897cc7631fa544d079c443800f4420d1b173f ("locking/atomics/alpha: Add smp_read_barrier_depends() to _release()/_relaxed() atomics") (that we probably want to mention in the commit message). Andrea > >