Received: by 10.223.185.116 with SMTP id b49csp1050946wrg; Wed, 21 Feb 2018 11:12:58 -0800 (PST) X-Google-Smtp-Source: AH8x227vmYjcJo1m2PbmtdWmq+3KKC9QTGdO/aryaNMY0zzEwGSWQ+4FRVq0dIRwvHRBz4Y8FtT2 X-Received: by 2002:a17:902:8214:: with SMTP id x20-v6mr4004640pln.182.1519240378618; Wed, 21 Feb 2018 11:12:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519240378; cv=none; d=google.com; s=arc-20160816; b=owguL1VeXmZ4aXXLo81lmNfz/O1Grc9Tf/Fx86sZ3s7wM/JQZJnu39DJRSnl1fj0kE 1MQ3a3Tkts7WBNGOPU9HL/jm4tIAnG+ojP5f+sNMtpZKxkolm6wuxoe/mceQoE076geL ET1VhLXvL04LAWYGnaGoUG8vbjRMLnZ8bVkLji48NWxgGTrbGTP8+3jQn0JQ0IzDiXND CMADjDd2u5QMMtKC02mWAqNBX0m+sbI923gKw0U0kq+cvfivlqx2zkgyw56/5iRzX1qd 79CK9/B4PNgL4VNMUsXyCuDyW6GGIpr8RLImmg2j9OO8lC+L2kT/PMYrww+hQEAqCu99 ZMaw== 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=OEqiuxXAE3X6d4gCxn13jiMRwK5nvlG4qd4+eUB729k=; b=M7OUipbbScnijY4Dwq0uZ0WMxj3QNk8Q1hpeYGJQATjp6+0S5jrqG8Mo56J3dhksbx ANAOvmf9Js8oZOEXLCvDNuROyyS3LBn17+n+grxD5cJFUcv8LnzhE9YFFeSJLPQ+oPyb 3dijLdeGXOuQF8Id4LY0mq6ug47gqFdZ8k5hykyPRac+K6FjnihBhoovMpzEecGzvKml PlT8kJLR8K+/bbd/hhjqX27oDJr1o/8N/CkIVX1CT186wzAoomJjxsntin8h/62iIKxi tZKQi4NrMxGv7NHg/xzXCcZbBOK+s3pOT580EW48jQd7F6qkpfN6xZ/vXTxmstKymboR t54w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EL2fOLxM; 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 c16-v6si2036792pli.330.2018.02.21.11.12.44; Wed, 21 Feb 2018 11:12:58 -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=EL2fOLxM; 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 S938913AbeBUR7J (ORCPT + 99 others); Wed, 21 Feb 2018 12:59:09 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:43692 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753941AbeBUR7G (ORCPT ); Wed, 21 Feb 2018 12:59:06 -0500 Received: by mail-wr0-f196.google.com with SMTP id u49so6942836wrc.10 for ; Wed, 21 Feb 2018 09:59:05 -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=OEqiuxXAE3X6d4gCxn13jiMRwK5nvlG4qd4+eUB729k=; b=EL2fOLxM7JXyhJHKbdNMSG8LKQtKOhY3o0ItcXYVUuHVisCi9TOg0Yi7SYO3ueZCr5 BmEk7sjdsbbbTuDkkmwiBS+8wS9V3FTBfG2N14o2ma/ihOiJoULUbP2s2Q/xV8kZkrR8 MFDXVOYxqxMmb2DyFLOUvPBUSmwvTkNFpBqZ+EcfmKSCNruw4jHlYNADvRMUVro61D+o h7n9wZtTEdbqVvrKFeFsTxf9XpDsaCJujm0nNtr1sTr8Se3fb8rO0i+62oRKCYxSx27v VAdPzO0zAEd+WDNPXkQV/YPLY1d3rJ0PKcfPgjFqrbMEbomF9H9ZkraQTPBz4yF9aUeU 6kgw== 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=OEqiuxXAE3X6d4gCxn13jiMRwK5nvlG4qd4+eUB729k=; b=MSwWid0N+9GIdgk/U0XfmkB9ZO7OFsK9aeSHVwEakiRfE+0wRABYgLVP98V/qMdLj2 rLktCHtVyEqYgOtZ/MGyyPdp17xb6PmeS6YhT+hfwYV8JqbYt2XxGAQ8KwTbg4kqKJcx AeSqzbJ0yoq3vkHRiDyzd3uFviBsvqkhrPqx/ndx2puBrOJ4WntkpN/P/GXKzLf7s7C8 YDRzbuOabPMJFkkM1bYKSBfz5JlPUiTbbOvlytHkdHFabIghnjCmuVNEDdgjqQzGGNas pPp2rwaaUcVxpEV0rV/X82dRa2PTuw4TWaZXcB8MO3ooXMm/AeapAwt4/Rk1+1HAIk6c dtDg== X-Gm-Message-State: APf1xPCDWpCe89VBWPUIqZhqNls7LLboS6wUpSy7ysN0PahmbEktl0TT szsSc4BS6YL3GbhjWKH9c2o= X-Received: by 10.223.135.136 with SMTP id b8mr3874150wrb.72.1519235944927; Wed, 21 Feb 2018 09:59:04 -0800 (PST) Received: from andrea (86.100.broadband17.iol.cz. [109.80.100.86]) by smtp.gmail.com with ESMTPSA id 69sm8399204wmn.41.2018.02.21.09.59.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 09:59:04 -0800 (PST) Date: Wed, 21 Feb 2018 18:58:57 +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: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference Message-ID: <20180221175857.GA23000@andrea> References: <20180221160602.GD3617@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 Wed, Feb 21, 2018 at 12:15:56PM -0500, 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. > > 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") Acked-by: Andrea Parri Thanks, Andrea > > --- > > 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} ; } >