Received: by 10.223.185.116 with SMTP id b49csp1442477wrg; Fri, 23 Feb 2018 19:23:25 -0800 (PST) X-Google-Smtp-Source: AH8x227AYnzLBR8xZAwOcfhtsamJMtaA8rnMgxAuMoNdOBGtE1hk6ni94Y9eAWguG/EyPdtyrzvR X-Received: by 10.101.86.198 with SMTP id w6mr3007881pgs.434.1519442605266; Fri, 23 Feb 2018 19:23:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519442605; cv=none; d=google.com; s=arc-20160816; b=lMRqwyIqCiVPoDXknYvukgLPcTrD+oOv9oilL9JJo1hozacraSaqC1p+dAMEfH8M8X qy6b7PmYeu7bqAeO6FVykVN00Y3lyTUj96IDiaeJyelTi17pFyAbAHteTdRG1XYb+BL4 M4WCYPu7Xgs21/6ehp6AGDRrv94LqQxUpCoxtO92+Wd2xE6gfwN44aOFQp9q0wwhpu7W nGJ3gt65F9ThcJpUit64zF3TUqwIjhs5+NX7vHN6FQ41OjqmRMooSjFbVH3OPSKUxUrH hJ7Ad/4bwHXngcbe56L9LH4JPRg1tFJdrcLjiBfOSkdTD+Pf5Z28I5ACgeSILTa6OpET 5Dyw== 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:dkim-signature :arc-authentication-results; bh=hYyQa2797Qz6pU368kWL5THoGiOGgUIXGc44lvXgIFk=; b=f66oAnhRRw7nzJIKF4ZCdQD4IPR63Ia4ii2v1oPKZyNvl2cdDG2yJ7Y8BoUw3IMXDL 5BGlP+FGP75Si0SZVQEljYYECX6vbHiUSgxyZfITk7fnEmbbOx2qxAxGB4p8RF8aE4yJ trKFEnF4wMS4Xx8ZtxDpBudTzNeJBGtqS+OpCN9Z92h6iuBH/O87Afw2XxxV5iD4Ttcn CrBFNWh1AG10FLbGlnKEpmV0veRjXRgxC7wWV9yf4L08QpD6EvL0nTE93EZnSJXKXcKj iv+mv7RQkmA2EEkpeQh7A2xf++aFCjtU0HqhTLpqI3FWxbjD0z0i++DreihMw/zj8PuN M4wQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hiA8pXgA; 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 m123si2330179pgm.698.2018.02.23.19.23.10; Fri, 23 Feb 2018 19:23:25 -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=hiA8pXgA; 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 S1752817AbeBXDWb (ORCPT + 99 others); Fri, 23 Feb 2018 22:22:31 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:42373 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751917AbeBXDWa (ORCPT ); Fri, 23 Feb 2018 22:22:30 -0500 Received: by mail-pg0-f67.google.com with SMTP id y8so4078496pgr.9 for ; Fri, 23 Feb 2018 19:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hYyQa2797Qz6pU368kWL5THoGiOGgUIXGc44lvXgIFk=; b=hiA8pXgAYmwPQ8NHjdo+5BTsqnL5vi8oHDFG40F1HfRqzg5mNl18ff6bFnFW6ohD8m K2Uhm49uZin4j3G9MQjQPFQPvDwTKopY0aQO1OHFmvzu0G6O++z+ZxVp2POLJ24uvI8O S/IzrHz3iGthzurcTCdCktL2XF3Z25XffYc91JFSy1PK1VFxJbZzmJN2FAM2exnoUckX vRUK4TnfSCUfvV8dhp/s7kGyzzY+CPzzYoiSJPRJtBRDS7idKVGV4BiXytvMqMOSXN0K zxRZ2m4LxAZamTFTp7NUm6waLi69VOMICiicNuW/GWrV4YGqXVVpleN9iGIqxdkLo4Rx TGPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hYyQa2797Qz6pU368kWL5THoGiOGgUIXGc44lvXgIFk=; b=Ep2A01L851Zy5uedZ8HoQvsT9BekmR+mXueRVwX+U6RwL3n6tR6gXPm7mzhiY3yzo9 VmUM3qvNtVxx0fAIyGfnO+0oNIPBkhviRE1muhxRmrpWq7aAzr64y9RewNzqNEb/5jRn 9N4zaHSImJ9RkA8tdk6HpF8mhda/yCEUabF/2jKtsciyGuKj43uEjuinccbNfRdj+TGg WwNanvOJXi9x1gxLEIeRADS0Gb3iTJ0jZ6dA6Yo3KS+6+Wpfw/EhCCH5ZJKkaYRV00U9 kKyG9Klua5LNZBXGozJvpb3SQruXN0VvKGOui7eoe7TWN0ZERKcjxHpRtOodtVfOCG3t xwPA== X-Gm-Message-State: APf1xPA89AgXc+m7peVDywUqIOinDiONhkNXhL7efWuakof2eDV1YI3n cYJyHI8wVyDmMGgP1Boi1ds= X-Received: by 10.98.105.9 with SMTP id e9mr3761343pfc.226.1519442549790; Fri, 23 Feb 2018 19:22:29 -0800 (PST) Received: from [192.168.11.4] (KD106167171201.ppp-bb.dion.ne.jp. [106.167.171.201]) by smtp.gmail.com with ESMTPSA id 205sm6859840pfw.77.2018.02.23.19.22.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 19:22:29 -0800 (PST) Subject: Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference To: Alan Stern , "Paul E. McKenney" Cc: Andrea Parri , 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 , Akira Yokosawa References: <74dbcbd4-6034-0be9-7674-ccb058de6177@gmail.com> From: Akira Yokosawa Message-ID: Date: Sat, 24 Feb 2018 12:22:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <74dbcbd4-6034-0be9-7674-ccb058de6177@gmail.com> 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: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote: > On 2018/02/22 2:15, Alan Stern wrote: >> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep, >> smp_read_barrier_depends, and lockless_dereference") was accidentally >> merged too early, while it was still in RFC form. This patch adds in >> the missing pieces. >> >> Akira pointed out some typos in the original patch, and he noted that >> cheatsheet.txt should be updated to indicate how unsuccessful RMW >> operations relate to address dependencies. > > My point was to separate unannotated loads from READ_ONCE(), if the > cheatsheet should concern such accesses as well. > Unsuccessful RMW operations were brought up by Andrea. > Paul, can you amend above paragraph in the change log to something like: Akira pointed out some typos in the original patch, and he noted that cheatsheet.txt should be updated to indicate READ_ONCE() implies address dependency, which invited Andrea's observation that it should also be updated to indicate how unsuccessful RMW operations relate to address dependencies. , if Alan and Andrea are OK with the amendment. Also, please append my Acked-by. Acked-by: Akira Yokosawa Thanks, Akira >> >> Andrea pointed out that the macro for rcu_dereference() in linux.def >> should now use the "once" annotation instead of "deref". He also >> suggested that the comments should mention commit 5a8897cc7631 >> ("locking/atomics/alpha: Add smp_read_barrier_depends() to >> _release()/_relaxed() atomics") as an important precursor, and he >> contributed commit cb13b424e986 ("locking/xchg/alpha: Add >> unconditional memory barrier to cmpxchg()"), another prerequisite. >> >> Signed-off-by: Alan Stern >> Suggested-by: Akira Yokosawa >> Suggested-by: Andrea Parri >> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep, smp_read_barrier_depends, and lockless_dereference") >> > > The change itself looks good to me. > > Acked-by: Akira Yokosawa > > Thanks, Akira > >> --- >> >> tools/memory-model/Documentation/cheatsheet.txt | 6 +++--- >> tools/memory-model/Documentation/explanation.txt | 4 ++-- >> tools/memory-model/linux-kernel.def | 2 +- >> 3 files changed, 6 insertions(+), 6 deletions(-) >> >> Index: usb-4.x/tools/memory-model/Documentation/cheatsheet.txt >> =================================================================== >> --- usb-4.x.orig/tools/memory-model/Documentation/cheatsheet.txt >> +++ usb-4.x/tools/memory-model/Documentation/cheatsheet.txt >> @@ -1,11 +1,11 @@ >> Prior Operation Subsequent Operation >> --------------- --------------------------- >> C Self R W RWM Self R W DR DW RMW SV >> - __ ---- - - --- ---- - - -- -- --- -- >> + -- ---- - - --- ---- - - -- -- --- -- >> >> Store, e.g., WRITE_ONCE() Y Y >> -Load, e.g., READ_ONCE() Y Y Y >> -Unsuccessful RMW operation Y Y Y >> +Load, e.g., READ_ONCE() Y Y Y Y >> +Unsuccessful RMW operation 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 >> Index: usb-4.x/tools/memory-model/Documentation/explanation.txt >> =================================================================== >> --- usb-4.x.orig/tools/memory-model/Documentation/explanation.txt >> +++ usb-4.x/tools/memory-model/Documentation/explanation.txt >> @@ -826,7 +826,7 @@ A-cumulative; they only affect the propa >> executed on C before the fence (i.e., those which precede the fence in >> program order). >> >> -read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have >> +read_read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have >> other properties which we discuss later. >> >> >> @@ -1138,7 +1138,7 @@ final effect is that even though the two >> program order, it appears that they aren't. >> >> This could not have happened if the local cache had processed the >> -incoming stores in FIFO order. In constrast, other architectures >> +incoming stores in FIFO order. By contrast, other architectures >> maintain at least the appearance of FIFO order. >> >> In practice, this difficulty is solved by inserting a special fence >> Index: usb-4.x/tools/memory-model/linux-kernel.def >> =================================================================== >> --- usb-4.x.orig/tools/memory-model/linux-kernel.def >> +++ usb-4.x/tools/memory-model/linux-kernel.def >> @@ -13,7 +13,7 @@ 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); } >> -rcu_dereference(X) __load{deref}(X) >> +rcu_dereference(X) __load{once}(X) >> >> // Fences >> smp_mb() { __fence{mb} ; } >> >