Received: by 2002:ab2:6d45:0:b0:1fb:d597:ff75 with SMTP id d5csp266738lqr; Wed, 5 Jun 2024 05:42:44 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWaVRQM2fXt6HwwyTW9LBPGs4zP5IEi+6hdtPlcvpggaGgFmV7Lh7FRIJgLnIag1/d1GFB6NaepS1m5Vd6/K3MP1+q2fXmKiG+gNyurYQ== X-Google-Smtp-Source: AGHT+IFnk3ghfJEKX4oC+c2GEXC75uuo8krMrnX4ukjeMjpOWZOyzRgH8ao6M8leFWdo7decAt4H X-Received: by 2002:a05:6a21:196:b0:1aa:5ca9:c565 with SMTP id adf61e73a8af0-1b2b6e4aab4mr2925227637.8.1717591364423; Wed, 05 Jun 2024 05:42:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717591364; cv=pass; d=google.com; s=arc-20160816; b=Lare35CU+OSpWen2a7zLnI850FT+2G5FFKrImuWYJyvKNV1LbeGAVhhU85LPfnXLMk tmyZhTKmXMOpg3XXGJRVfZuYa6SLsmdEB1jS92lCaSo7EEJ6RAH4dk5toDCtqzNM5hsL HAEDzO1Ystu+ddPR6ZajBY4N55bG8LACArUKUWbqlOa51rpd0N0q7eFWF7Ho0pJSx0rc 7tQJ7HhW5lreskci8AwWRFXnnawT57GMyPDeELYd5bLUXyOurtbf+0m/4ICh/4MzB1G+ aL9ELrwKfWowsFqjSGKVU01tC0K5HKeqHLbQ9CThdZdcO1RmAxxvZtHsFvSDcqaMm67E MzFA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=zaouCv9rm2teZt+a4Uo1mMtttdrN3wv5HXn4etE7VGE=; fh=nf3ovOfdQghXvQv5Vz4ewb7YoeAguyjA8kuKjKyDgTE=; b=TKKUVj0Yfo0uJDm9xQ7I7Nlj4lez7F872X2DlJv8/WCG493IM+MZSZ3IxktyRFaDyE ZAxJ+JTCUK4nXYKRuNCAvNB3h2YQwW1Ih8YIY9dmZ4sAnO2zWVvRuadekHYjAaWi/+rr AHAEySg6lBGVz27wpJ02ihEQ09gjygWcszE8Cn0ILRtYjYUwKpd4WKtrmshYFDRtDyMP LzZ1sCAcVIn5FOv7QTv+xk5Nm8IWvGURDIsl4/oMhMfsCvi/L74JJFMbM0iAaxz3km8s 9bLMN3WPg23MeM2rxomQww4IH7sOY83eYJxbgemq/sBL2raSaeYMHc34h0YGCXOtbEBA f1mA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=m+nQWdQr; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-202433-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-202433-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id 41be03b00d2f7-6c359e09dd8si2745257a12.381.2024.06.05.05.42.43 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jun 2024 05:42:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-202433-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=m+nQWdQr; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-202433-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-202433-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id F176BB272EA for ; Wed, 5 Jun 2024 12:23:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5EB3819AD60; Wed, 5 Jun 2024 11:56:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m+nQWdQr" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B38D19AD4D; Wed, 5 Jun 2024 11:56:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717588586; cv=none; b=e7Q8L3M9H+zk2jcd2xs22/SOR+g66NI7hx0AUDw28FxFvIid5DyLbQCJXkQPNUrcNRULMPjhkd91fsXstwMIGm5Pydc0dByK4qdiy/zOnwX9sbb1AB98x9f0d+0mN34nC62LhT6jKb5hp0vyAoBjTb9+mBINhkJC4+T5Wck1MbA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717588586; c=relaxed/simple; bh=MQYsWFBeAynMryk/Gyt9yTWjflv1cv5n6aWLBDe/SFo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RUveI+6hrT8Z94EVHuFdujwJjuhTFnxzcH1p9rwyHM2ZssiJVo/HZnNkQ2koZ+YHOZM0fN7zHmMMGK6FSgmTiJuQVBTbLCAp596vvBXLrPjNnkQm0E20JdWlYSbriS2oVS7AbgzI7YoG+NymKVYeeBT8dxYpFmUqDCZMR8ZkgtA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m+nQWdQr; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA128C4AF07; Wed, 5 Jun 2024 11:56:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717588586; bh=MQYsWFBeAynMryk/Gyt9yTWjflv1cv5n6aWLBDe/SFo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m+nQWdQr5oGfrnskMQzLWboTz7AK+E6POtbk0O+zGu+62bG5UD8QbtKGVRg8SrsMG 8oUBjkoDi9aPSNdSAGyuN6IMtpMrdgxhrVF+zFWmAbW42Dagp/BQn55I20stO6VNZG sKAx599Yi08sXUjeA12P1rtkK82FidRX7NCo15Et0ia1HBXkssWHPVEdCjuM/ALe/0 V/Oik0M6CLAbwNfEeazAtG+3mhXOyaVXj5zy54ZjzZtdEPOYgUz7mXz+0O9/cGW/UN zmun4M84sFxBvam+MYlG6P07r0Ornk+V7FPmDUjO1MmrLmjEQG5ODYP8dLSafi7Nvt BI1g4IRc0pomg== Date: Wed, 5 Jun 2024 13:56:23 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, rostedt@goodmis.org, Rao Shoaib Subject: Re: [PATCH rcu 2/2] doc: Clarify rcu_assign_pointer() and rcu_dereference() ordering Message-ID: References: <20240604222155.2370541-2-paulmck@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240604222155.2370541-2-paulmck@kernel.org> Le Tue, Jun 04, 2024 at 03:21:55PM -0700, Paul E. McKenney a ?crit : > This commit expands on the ordering properties of rcu_assign_pointer() > and rcu_dereference(), outlining their constraints on CPUs and compilers. > > Reported-by: Rao Shoaib > Signed-off-by: Paul E. McKenney > --- > Documentation/RCU/whatisRCU.rst | 30 +++++++++++++++++++----------- > 1 file changed, 19 insertions(+), 11 deletions(-) > > diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst > index 94838c65c7d97..d585a5490aeec 100644 > --- a/Documentation/RCU/whatisRCU.rst > +++ b/Documentation/RCU/whatisRCU.rst > @@ -250,21 +250,25 @@ rcu_assign_pointer() > ^^^^^^^^^^^^^^^^^^^^ > void rcu_assign_pointer(p, typeof(p) v); > > - Yes, rcu_assign_pointer() **is** implemented as a macro, though it > - would be cool to be able to declare a function in this manner. > - (Compiler experts will no doubt disagree.) > + Yes, rcu_assign_pointer() **is** implemented as a macro, though > + it would be cool to be able to declare a function in this manner. > + (And there has been some discussion of adding overloaded functions > + to the C language, so who knows?) > > The updater uses this spatial macro to assign a new value to an > RCU-protected pointer, in order to safely communicate the change > in value from the updater to the reader. This is a spatial (as > opposed to temporal) macro. It does not evaluate to an rvalue, > - but it does execute any memory-barrier instructions required > - for a given CPU architecture. Its ordering properties are that > - of a store-release operation. > - > - Perhaps just as important, it serves to document (1) which > - pointers are protected by RCU and (2) the point at which a > - given structure becomes accessible to other CPUs. That said, > + but it does provide any compiler directives and memory-barrier > + instructions required for a given compile or CPU architecture. > + Its ordering properties are that of a store-release operation, > + that is, any prior loads and stores required to initialize the > + structure are ordered before the store that publishes the pointer > + to that structure. About that, why rcu_dereference() isn't a matching load-acquire? Thanks.