Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1417016pxk; Mon, 31 Aug 2020 20:00:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqFMjKjnLy6u2s0NwJfoboQWralU10r4/XJygYKlCU4pFoEXsl+ZF2o1DLt2qhbyFHBbbJ X-Received: by 2002:a17:906:1589:: with SMTP id k9mr3511172ejd.115.1598929228495; Mon, 31 Aug 2020 20:00:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598929228; cv=none; d=google.com; s=arc-20160816; b=bpj0UbQl57V+0OC/2mFh4HFPxzeTtFC+nfu1Lt5YQBo2VZKoy6bs/mvu+it3bT4AgX 0l3YUcbK2e3RmLCR2e+vSNMDyVgj68n1x39eA39J5WD7CtApmwFYQTbnjiVGAizgs/Qc NbSTwUxMnZXvh30MlYBdMNRtjpzEp9zGH/MC1Q9eoFfyKc7dfw9/Wm4jam8mxf3uJhYc C692efLynzNn7nhqLFrQjeqepcyPecfzl9SRAHSnZPTh3nNOv6ID5qEku0nDE86mo5JC K8nW8ETO4rFHxrsl8BQBSfOnmN4AkOq44cI9Hs/jas28+2PuP+5uRfY3FEgoHnjd138g wvLg== 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:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=iFvn7nONUdvf4FtBNlYMuWkIaI5PRKkrA2qlgssGXl4=; b=AXjJKGccnuRpiv8jIeCIhAVUfY9IpT0hW3boQbowgHFdotQM57SqZHvFqBJNS6ix06 1eIajrH12w78wsMENewt6wSw0kDz6qa9ckIjJoRuuC8XgE0W/hQxpLqNGS7mnC5L4Bv9 z6SoE2zKmnHd8ZI9lmV0lEyyIB5KM8FigoJizIpdsiW1fs36Gu6OS9nGzJr534iay1Lg uH9/2MXMEJpMMFMK2Kifr3tG/eO2bJmtMzh/i37zqdYp8kchA7Rig0tc/UHMzuPWyeAp M3QkIEkwPhS/xgTh2gHSewG4umqXRL+/2QCWD+sWSbEeyKCpQFTNVSAidjKWCdlAQtNI LQ6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="RcTznFJ/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ci4si6646374ejc.612.2020.08.31.20.00.05; Mon, 31 Aug 2020 20:00:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="RcTznFJ/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726467AbgIAC64 (ORCPT + 99 others); Mon, 31 Aug 2020 22:58:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:55260 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgIAC6z (ORCPT ); Mon, 31 Aug 2020 22:58:55 -0400 Received: from paulmck-ThinkPad-P72.home (unknown [50.45.173.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F339E2073A; Tue, 1 Sep 2020 02:58:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598929135; bh=Kl90djY9Z+jLZiVePHoF79IH1UsM/genhw7o/0XlZYA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=RcTznFJ/0I8CL7E0JV7trzqKIt8bfB8EMhfUfqDqkR4Z5iYCCM8UvkaUTJPQH0l7l afmfoLVT6lw9aoLC6k0kK0dgRigXB1g39RoRHIzG9RRNJnjxwd2TWMsj3B5DGGHKPb vp/nop1I+TLTzhD0HkcjFAbChozoeW14DRXvENGg= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id C220335231E8; Mon, 31 Aug 2020 19:58:54 -0700 (PDT) Date: Mon, 31 Aug 2020 19:58:54 -0700 From: "Paul E. McKenney" To: Alan Stern Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, kernel-team@fb.com, mingo@kernel.org, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com Subject: Re: [PATCH kcsan 8/9] tools/memory-model: Document categories of ordering primitives Message-ID: <20200901025854.GA29330@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200831182012.GA1965@paulmck-ThinkPad-P72> <20200831182037.2034-8-paulmck@kernel.org> <20200901012309.GA571008@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200901012309.GA571008@rowland.harvard.edu> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 31, 2020 at 09:23:09PM -0400, Alan Stern wrote: > On Mon, Aug 31, 2020 at 11:20:36AM -0700, paulmck@kernel.org wrote: > > From: "Paul E. McKenney" > > > > The Linux kernel has a number of categories of ordering primitives, which > > are recorded in the LKMM implementation and hinted at by cheatsheet.txt. > > But there is no overview of these categories, and such an overview > > is needed in order to understand multithreaded LKMM litmus tests. > > This commit therefore adds an ordering.txt as well as extracting a > > control-dependencies.txt from memory-barriers.txt. It also updates the > > README file. > > > > Signed-off-by: Paul E. McKenney > > --- > > This document could use some careful editing. But one pair of errors > stands out in particular: > > > diff --git a/tools/memory-model/Documentation/ordering.txt b/tools/memory-model/Documentation/ordering.txt > > new file mode 100644 > > index 0000000..4b2cc55 > > --- /dev/null > > +++ b/tools/memory-model/Documentation/ordering.txt > > > +2. Ordered memory accesses. These operations order themselves > > + against some or all of the CPUs prior or subsequent accesses, > > + depending on the category of operation. > > + > > + a. Release operations. This category includes > > + smp_store_release(), atomic_set_release(), > > + rcu_assign_pointer(), and value-returning RMW operations > > + whose names end in _release. These operations order > > + their own store against all of the CPU's subsequent > ---------------------------------------------------------^^^^^^^^^^ > > + memory accesses. > > + > > + b. Acquire operations. This category includes > > + smp_load_acquire(), atomic_read_acquire(), and > > + value-returning RMW operations whose names end in > > + _acquire. These operations order their own load against > > + all of the CPU's prior memory accesses. > ---------------------------------^^^^^ > > Double-oops! Hey, at least I am consistently wrong! ;-) Fixed, thank you! Thanx, Paul