From patchwork Tue Oct 8 13:50:32 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mathieu Desnoyers X-Patchwork-Id: 13826522 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B2E7CEF177 for ; Tue, 8 Oct 2024 13:52:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 460426B0092; Tue, 8 Oct 2024 09:52:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40FF66B0093; Tue, 8 Oct 2024 09:52:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B04E6B0095; Tue, 8 Oct 2024 09:52:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0CABC6B0092 for ; Tue, 8 Oct 2024 09:52:45 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6BD9DA1CD1 for ; Tue, 8 Oct 2024 13:52:42 +0000 (UTC) X-FDA: 82650575448.19.A185BEF Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf03.hostedemail.com (Postfix) with ESMTP id 236742000A for ; Tue, 8 Oct 2024 13:52:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=JUhZup11; spf=pass (imf03.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728395429; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KqLVqymiLubFOx8t5GxWwHY/o6+WmyMaWWla3hOXDIE=; b=XhYAxC992fmmGhj31kybUu/i8SHiv9vTn1JZOn7eeCKfcCiBjDrk8HvzDCyyeECSzEtmQB /5mIlvlA0KSfSHz53eWYsH6C64n5qpSJbe5OYo/08HI/lpzCV9+fJHMbXVX7HTOXbGmwt0 0Qn2hhE2+wTJNKG1av0y6z3ix4TFanI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728395429; a=rsa-sha256; cv=none; b=3wDeHKZo/l4NswexdFd+i71DIvVmJweLGnNdli2QLu5gJA7HDwX7QDjQyqTRJ8/i2tVcNF pyBXcb0HT689livKF1TYeVPW2UnNvvCEV/PcNJk4P5/7M8s4FjRE4EnXXfHkaPsL1wJmNg JC7KtO2z4sML42zN0IApZAGZhXNd5FI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=JUhZup11; spf=pass (imf03.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1728395562; bh=yje+Nf53ZMDX2ciH9OYWiJcxOcJxvL0v/cML/xD8LJI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JUhZup11xZUM5lXz8AmFl7eRRRbNdTVJn/MAouIeqyExpdpC7wwzSy9hI/bDD7sTZ zMS9WBOhOM6injeA4saJAsztMqLPoIHRVPMs9V6IGJ7OLZUFUAbHuGH7I2h3JMmPTM dKXT7l/hdTnifrGM8Nctf6T/VvE4JryCejgDRtQ4aIiW7NFqaLuyjMnDIEkRXQC2c8 AXZBOW/Lg9c/MmCwqVIp60r7R/DHkbkd9yjFgUEQVD48fYXvqco8rKZLfZNJxTssgk QctXWViwcxB7jAFx2bZZGRV7318YPgpZOPtHD0kNVZsevNkm7LfIYya52amK3TQzov ly7soWyCuYxoQ== Received: from thinkos.internal.efficios.com (96-127-217-162.qc.cable.ebox.net [96.127.217.162]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4XNHX965gyzLcG; Tue, 8 Oct 2024 09:52:41 -0400 (EDT) From: Mathieu Desnoyers To: Boqun Feng Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers , Linus Torvalds , Andrew Morton , Peter Zijlstra , Nicholas Piggin , Michael Ellerman , Greg Kroah-Hartman , Sebastian Andrzej Siewior , "Paul E. McKenney" , Will Deacon , Alan Stern , John Stultz , Neeraj Upadhyay , Frederic Weisbecker , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , Mark Rutland , Thomas Gleixner , Vlastimil Babka , maged.michael@gmail.com, Mateusz Guzik , Jonas Oberhauser , rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev, Gary Guo , Nikita Popov , llvm@lists.linux.dev Subject: [RFC PATCH v3 2/4] Documentation: RCU: Refer to ptr_eq() Date: Tue, 8 Oct 2024 09:50:32 -0400 Message-Id: <20241008135034.1982519-3-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241008135034.1982519-1-mathieu.desnoyers@efficios.com> References: <20241008135034.1982519-1-mathieu.desnoyers@efficios.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 236742000A X-Stat-Signature: ysuf67x7zwe9h64ungsk66okrc6ci53q X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1728395562-516341 X-HE-Meta: U2FsdGVkX18joZvZbRcw4AaXVt0ll/pSEUTbj558B0XOPZ0dkmmilc/P58Tab1aWdUMUm0pS7V29WQUhmbO1zKk6Nel9D6XaTq6TvKyBA6QoDL8CgesyUzgOALgUSh4KL+vQmy88FRfpZrdHR9MolAGSnLl+Kiyjtqv0sReXpoI3rjRQpyw7CagkZspcNeALo9Z00B9jYYX5+Ht+/U6wsXyvfC7bbg1wLWFoMuYQcBG0i9CiVyTsfd1d1LY1mRKnFl4X6LZ0W1pmik/TAm4J+lxYGti2n++4+j0qXgS1b10vXaJjC1emWwWsfgj6GF5YubxqRMeQqoEHIndHdEvpO05tebDLvv8t2/58xrL4EdBZCLYNecoxuxvZQQyM24rJZMjr1QO0XNxSMWTCIJqqrLrxwsO5Bob8oANSWepZxpCu/5q39bHP8Wr8ybtVmGkqno4DiLby/pjaaCsqJ9In8ijCHyHPdSnpR1xUSv3pyZCB1e4n+MSgNluLoWYTw8wxK3q+ZzIfkEBg6eOU99mVVqkKEEkFpbdDT/H+U4m+QSh+CDvdtzWXU0t2gcI7Hm8xXPTCCGXKYOvWB1MAKAEWZ8T/vLtgJJ9XuGsfcB98NPJGadrc0H8E3nY7Z0oTP1Tn0I4wcjKZULu0ZXo3jQoTJd3wTPoK0oYSbHflPmX2+Snwe52ZscErvGQKZLtCaDKjm32pz0GBAaOVVjQ5S5u0Z2xkwRTXsRHQUamElQ2OQ7JnozY3wS3RISUjq9gUcp9/odAGZALvC83VmVitw3fAtqeibDKsSshnV0WORFQiUWyXyeOexCHvYEIWka12r9sxTVGPLQjhgObPyPZV9izgmQ4B1J+YNqsTAErJc4zeqqrxbuyiqieQmQx1Nb1R3pR4REFWE+HM4sOfSd//Bn6u6KcaRZCBuZP4sgdKGLPJ6loB/qTuwCWuuDC2AV2A2ORZKNpSQKbZAbhmOiEYfIp lvyL0wkN Nu/5Czrfs3VBLlGBvearQRG0Gf0uUAsBaJKz7sa5fobX+kB1UKHVnRCSu8NHQoZHdEyX0TURIxddAuKozrBG1ekgAQu7Cs02iQyIQa9tUKmPLnotFnw15yKBP7p70mW4JRdc0fFPe4PuBs0oqku/MKCc9MLwXXNy5armk1SU2UrC69PEWXxwG+LNYHPFrTHjZ6bBsPP7fSTYOWL+g+I56mk6jN/zrikcxGL6u92YDtY+LECUC620POAJ2vV4kmAJFEraMQHOoik7saQDHlrl3VXgOJpc21iPHmR2A6u1rjyammMrsiq/eqGfeOfmPRitwcPK/NoNY+PsQUt/OZFw3Dl1fh3yiBQCon+L1apqYfFbtbXk8q9eQp/zsBGIACHBfj6IVwA0Y7FmBn40xWSv8j8+66dTeyqPEVFkiatSdB3DRIC7eQH9D4ZXMC/ebj8qpoW6SG9N9mbdPbZaVlwWVOQuAoT0zO9Yaoz0UBNnstIYsp+hnlm6repjig95rKRel6jjqeUWXZ2GHj/kQ/9oYJXS+YixucR6477dOz9weyE2taAaWLAwlI7nJdNVUtPM0mavW/juLOe/wT4mIHkdrpureqzuAP+veZSRke6b16vqejVraSX6fqT7d0fFpUnluKKastcpg3b3iZ/YiaucgtLJvDQjwv/XLzoc66XboBydjxFdx3XFC+McePVovwJ6Rouy+rb/5FI5O2hiv9zhQzZ36rqs4aa26ykJnudDakQ+J2b05+inj7A3seL6Y2/hPDzxDBCZ8ZK4KuyoSmnEfPNc/cMeEfBpEWEYKahiZTN5L2wbj4gzsGu9O79XeS3H8kFavnQmtIorIRSwLVTkrOY/HBr5VwOZYCgqYBV6b9BnMXoWjDU5uhdlDOkEmvDL8Wtgd1IIm1SoABuG6pygOWdnaixUqx7le/+Q3LG4iw1WSGn2uIIbRQobty2UqjqFZ60EVmUC8BIPvt4U+eG305eSNGD2l zTjuOKFq XtqByr0WdQ3/GG2N56P7blpKjlZ6iqOR6lqjquvgPSC1WP05FWNQVhbqkqqgb0+7ZSB0bQouEfrknAnhPcmcE1A94ipeB2K0aZ4TAPvJQ8C8jz+MkKcUbFLiXlqnBMIovbAiM6ZEqiasR+ary0PMHS4LmH2U1BEJP9FVjZaROztfD6YDoKSc7g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Refer to ptr_eq() in the rcu_dereference() documentation. ptr_eq() is a mechanism that preserves address dependencies when comparing pointers, and should be favored when comparing a pointer obtained from rcu_dereference() against another pointer. Signed-off-by: Mathieu Desnoyers Acked-by: Alan Stern Acked-by: Paul E. McKenney Reviewed-by: Joel Fernandes (Google) Cc: Greg Kroah-Hartman Cc: Sebastian Andrzej Siewior Cc: "Paul E. McKenney" Cc: Will Deacon Cc: Peter Zijlstra Cc: Boqun Feng Cc: Alan Stern Cc: John Stultz Cc: Neeraj Upadhyay Cc: Linus Torvalds Cc: Boqun Feng Cc: Frederic Weisbecker Cc: Joel Fernandes Cc: Josh Triplett Cc: Uladzislau Rezki Cc: Steven Rostedt Cc: Lai Jiangshan Cc: Zqiang Cc: Ingo Molnar Cc: Waiman Long Cc: Mark Rutland Cc: Thomas Gleixner Cc: Vlastimil Babka Cc: maged.michael@gmail.com Cc: Mateusz Guzik Cc: Gary Guo Cc: Jonas Oberhauser Cc: rcu@vger.kernel.org Cc: linux-mm@kvack.org Cc: lkmm@lists.linux.dev Cc: Nikita Popov Cc: llvm@lists.linux.dev --- Changes since v0: - Include feedback from Alan Stern. Changes since v1: - Include feedback from Paul E. McKenney. --- Documentation/RCU/rcu_dereference.rst | 38 +++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst index 2524dcdadde2..de6175bf430f 100644 --- a/Documentation/RCU/rcu_dereference.rst +++ b/Documentation/RCU/rcu_dereference.rst @@ -104,11 +104,12 @@ readers working properly: after such branches, but can speculate loads, which can again result in misordering bugs. -- Be very careful about comparing pointers obtained from - rcu_dereference() against non-NULL values. As Linus Torvalds - explained, if the two pointers are equal, the compiler could - substitute the pointer you are comparing against for the pointer - obtained from rcu_dereference(). For example:: +- Use operations that preserve address dependencies (such as + "ptr_eq()") to compare pointers obtained from rcu_dereference() + against non-NULL pointers. As Linus Torvalds explained, if the + two pointers are equal, the compiler could substitute the + pointer you are comparing against for the pointer obtained from + rcu_dereference(). For example:: p = rcu_dereference(gp); if (p == &default_struct) @@ -125,6 +126,29 @@ readers working properly: On ARM and Power hardware, the load from "default_struct.a" can now be speculated, such that it might happen before the rcu_dereference(). This could result in bugs due to misordering. + Performing the comparison with "ptr_eq()" ensures the compiler + does not perform such transformation. + + If the comparison is against another pointer, the compiler is + allowed to use either pointer for the following accesses, which + loses the address dependency and allows weakly-ordered + architectures such as ARM and PowerPC to speculate the + address-dependent load before rcu_dereference(). For example:: + + p1 = READ_ONCE(gp); + p2 = rcu_dereference(gp); + if (p1 == p2) /* BUGGY!!! */ + do_default(p2->a); + + The compiler can use p1->a rather than p2->a, destroying the + address dependency. Performing the comparison with "ptr_eq()" + ensures the compiler preserves the address dependencies. + Corrected code:: + + p1 = READ_ONCE(gp); + p2 = rcu_dereference(gp); + if (ptr_eq(p1, p2)) + do_default(p2->a); However, comparisons are OK in the following cases: @@ -204,6 +228,10 @@ readers working properly: comparison will provide exactly the information that the compiler needs to deduce the value of the pointer. + When in doubt, use operations that preserve address dependencies + (such as "ptr_eq()") to compare pointers obtained from + rcu_dereference() against non-NULL pointers. + - Disable any value-speculation optimizations that your compiler might provide, especially if you are making use of feedback-based optimizations that take data collected from prior runs. Such