From mboxrd@z Thu Jan 1 00:00:00 1970 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 A417ECF6496 for ; Sun, 29 Sep 2024 00:20:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFB796B0191; Sat, 28 Sep 2024 20:20:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E85056B01B1; Sat, 28 Sep 2024 20:20:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB0676B01F0; Sat, 28 Sep 2024 20:20:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A78936B0191 for ; Sat, 28 Sep 2024 20:20:25 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 60FF9AB265 for ; Sun, 29 Sep 2024 00:20:25 +0000 (UTC) X-FDA: 82615869210.21.3AA993F Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf21.hostedemail.com (Postfix) with ESMTP id 72C201C000E for ; Sun, 29 Sep 2024 00:20:23 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hnsOnWnh; spf=pass (imf21.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727569100; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AciA5lkArq2LcuAgiidbmpLX8//NU2EZPXWMWey1klw=; b=C2pbA20+jQDHzD7LNwKI4n7JKmM5mj3snBcqe6AYhh3CAN5FgZzfC5ghQSw3MX/pevqWZx D/yb512q6pOt8mHsiWObF3QFI5ddVhMSASdKzl2LcjLPSvbRf423pOG9xzwvyi/41QPj1t ruzDgvNg083tOE0azrbOPUE88O8Ur1o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727569100; a=rsa-sha256; cv=none; b=f/XtMmrifyQDqV9q3gia/k/n7NOLFdh58nWDzEXMIVIRzcRo8egsve6pWN6e2Yd+qJ+R40 HGR2NbN+Kocm1bbEqtaKqF848i0DGvI8yC768nXlt1AXiT+oyu+rWb9EzUdwyt6X0m0ikW DdNiTxLtsjuWeP4QvK3jFKYTLR6CHsE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hnsOnWnh; spf=pass (imf21.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-71971d2099cso2630299b3a.2 for ; Sat, 28 Sep 2024 17:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727569222; x=1728174022; darn=kvack.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AciA5lkArq2LcuAgiidbmpLX8//NU2EZPXWMWey1klw=; b=hnsOnWnhPVXXjbobJYymshj1brRJSab/IGnZR76T39O7I8dQw/Sr3+6k2+kMouu7S5 eriQlm+K7rEACcF3FHE/DoB2klf/sLJCMWgNmhG6nvATD3iaYx2spl+OaNzZr0BP6KeX /tRkGthe+IykKlw3LchmeoU6uBfZqNIr3nUCblr61tBS9ENfD6wa40DGs5YUXNkVMTM2 hgB3dLj19tmyXbzV0oPZFoDWWmLfGDdwuNtFHNOjoBfDVKiOioCEnW4LLFWnlJv6jdME YRyAVgo1UVxI6w/cKSSNg7w1uSr8zEDVK8kiqeke6EJiieUHhcSx1scnqLVfQBAIkTx6 tv3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727569222; x=1728174022; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AciA5lkArq2LcuAgiidbmpLX8//NU2EZPXWMWey1klw=; b=Kx744/PTvGDsYF+yxPwxscqi40BT3rfXr9c/Cb4MNPGoCNO3c3d/BWr2Zwd/WtnGyf W5lSPjkXD0+KOydyZDlKfEC19D6DuJ4Ib2lV9k/6782grPlNvHJMlUMGrUFwxYxAzrXq bWDDRHDk5akfo6tkT8BZg3AZ/+P6v7OWuqPaq20LOj7mq9qOTroE6tgMWQ4ZTheyT1Cy toH38HYSo0KEsrcXrDe11Sc+q0W/9xQrlLfuYy6IjB5752t3L7TYZKoWkF5mHFY+glWr /g6NV9o0bJOT/xdGzYG+0N3XFBJSXS8CXnn4QAAZa3iRNj0fLUvr1N5AvQ2GTxuD8nC6 UN9w== X-Forwarded-Encrypted: i=1; AJvYcCWZlSTFeKCa6YjJu82xcCt5SSdYgbHat/jywTPtV7hb7E6DVePKgXOm1cuwivZO938voBXqjd/iIg==@kvack.org X-Gm-Message-State: AOJu0YzCWhxbVW7KyvyKR2pisbZfsBwUF5TLAE4CUiqjGfYzqQ63y59n e/al/z+faDJAu4VEKa0zlGzVyM5ObOYwmEPT4XkdGBS4i5tEIj6H X-Google-Smtp-Source: AGHT+IGrPCIsZd3xVlDfQ3t7v5wWjb0n8Dw8h91/C6QpaBBBIkYhcxX80aGJo1MfszwJ4cOHtuUW3Q== X-Received: by 2002:a05:6a00:194f:b0:717:e01d:312f with SMTP id d2e1a72fcca58-71b26078cf5mr12778522b3a.27.1727569221947; Sat, 28 Sep 2024 17:20:21 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7e6db2b390dsm3889001a12.20.2024.09.28.17.20.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Sep 2024 17:20:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency From: Alan Huang In-Reply-To: <60123be5-ae24-4426-b9ca-6f39e64ab76b@app.fastmail.com> Date: Sun, 29 Sep 2024 08:20:01 +0800 Cc: Mathieu Desnoyers , Alan Stern , Linus Torvalds , LKML , Greg Kroah-Hartman , Sebastian Andrzej Siewior , "Paul E. McKenney" , Will Deacon , Peter Zijlstra , John Stultz , Neeraj upadhyay , Frederic Weisbecker , Joel Fernandes , Josh Triplett , "Uladzislau Rezki (Sony)" , rostedt , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , Mark Rutland , Thomas Gleixner , Vlastimil Babka , maged.michael@gmail.com, Mateusz Guzik , Gary Guo , Jonas Oberhauser , RCU , linux-mm@kvack.org, lkmm@lists.linux.dev Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240928135128.991110-1-mathieu.desnoyers@efficios.com> <20240928135128.991110-2-mathieu.desnoyers@efficios.com> <02c63e79-ec8c-4d6a-9fcf-75f0e67ea242@rowland.harvard.edu> <2091628c-2d96-4492-99d9-0f6a61b08d1d@efficios.com> <60123be5-ae24-4426-b9ca-6f39e64ab76b@app.fastmail.com> To: Boqun Feng X-Mailer: Apple Mail (2.3776.700.51) X-Rspamd-Queue-Id: 72C201C000E X-Stat-Signature: miebi5dhug9mht8eikibw4x7nrdhmxm1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727569223-797086 X-HE-Meta: U2FsdGVkX1+XIMCsWC4xENam3SCUYhsXSwwjwCioX5wdSRiQKI2pzkAltGVAnCNmQFOv/CcN0mNLfCbGExNkiOupMX3GBlEjJxqeW1/tlzfzsOKnrtIg0J+7Zpc4VDrojUi9TU+u4FNSO6p1NhrSofq9InPGMMJi8WQ/NpkVkJfalbOGFXgGe1MhEh8eVciVEEU20Yf8VprffDiBaaiJKCXzs7eof4ngAF3YRI1RVeF098O9hDEhETgJSP4AGIGFBJiUkmsoS3QDLAgJfK7dU85F/wwuM0xT1XEpqyfi1FrLd8YafWNX7hTqTuflaDgJIOd/gRPcD+9glO6kDZnku4T81lYCQXsUdskFSMVEbN/xjHAhyOhgTQs9BxWEdSBvrtE3xIULosn8IlPGVGoupMJqz1sg5YNSWK13Mly/pbkM5F5PSE3zER33ODICcPeqBcdar2G6+/WraU1a/Gdf+ZR8YTrU1UlCVMD+YM8T6Afa+zLE8QF2LFPOEMtwtLZM3rblKzskPDfSPDF3UhK3d4JlFKwNrrVSdRRZ9xjj04VK1DA/2EZC2TDis+AO+5i+zIXCBTNnnP6VvlH6v4g+NLkPTn49qlMK7Uz2+6jrOp1iyUfGkN1/VdjSe9uguq1UJyAb6P9Xnne3W1jf6t98Es8uLRY/jRqmt9wuK3KQmyb/SWmwwnilM+a5vJ2rZnqcu+GQaAf+klCXimhb7rOxTKcuNMpUZI1E3MfQnUYE6E+hCHredG9mF3vd6OirATsp+g2kYMukS7Jt1626xPnuobedHm0dqPAhLY9O5JeuZkCFIp0KYTLOxgjBcPfTMVV5TmRyQX6+MdXx6gnljJiPitYh9Vx8AFuMuvHsgl/Tc4g+qSJHNohDymgGSDk7KuOqTQBxcbajNlpzXRHcOoLAFiN8aKYz6tr3cpGLQB8qqPIMDw36vYm0MB4CX2TUGH84rV5QGcs7USKd8zMKMFr HNAyhNCA JZnkMhQnw/67c5ERyDRD/jk015RE4uVWtwvwdOoBCvTLj/PdtjtLJB5ZmsP6m1a6ybxjhe8Cz1A1an9/ft9kuzFzvMplL1Vd+27nNzvpuPuHrOfCOPvAPEV6hOdE9Mr1/z5h0VilGhNbtyzAICsCIWAMePqhIh1u++HuXpMa4vdj70LRYsI73fVF1QyB+FoyjVpYVrmAKgImpLi78vVhlEqFBQzvzRuIgjeZcbKpIUTeSV8+eKR8TNp7Z0xbpMNPr3qoSCpRZNAm+z60nw5AkJ4oSmXpOrcRrI6PRzfIUxHJ88VJFS65wIEVXtyjSa2xgaRX6K0y7zLh+x26IwvwVGFA2+TO1uohT/IGRbbbPzqlYqU383B7IcwEGn4tioFy8Khc6aCJI8kQbf42Auf9r+22PG6mfLdl+2IKdj2YbxrXCmpUOygcb6H5gneCt9n9ozftUItbWcI71l4xCM+Jec4j9Xni6DeDoSVjioPJhJvipn/gcTcoZLrifcadjeGQfZFcB/mGtPFzgXTNWF7jKwSq+0VM1AOBvBqMeME33l2W/Ww3xDJmxpG+oB4zdj9wX5hc7fJZAySyaPaLcC37mtm8Cn4sXibZbYVid5okTM/qhV+Lu3K5RQ6CnXKgHLGmNf8tW 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: 2024=E5=B9=B49=E6=9C=8829=E6=97=A5 07:55=EF=BC=8CBoqun Feng = wrote=EF=BC=9A >=20 >=20 >=20 > On Sun, Sep 29, 2024, at 6:26 AM, Alan Huang wrote: >> 2024=E5=B9=B49=E6=9C=8828=E6=97=A5 23:55=EF=BC=8CMathieu Desnoyers = wrote=EF=BC=9A >>>=20 >>> On 2024-09-28 17:49, Alan Stern wrote: >>>> On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote: >>>>> On 2024-09-28 16:49, Alan Stern wrote: >>>>>> On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers = wrote: >>>>>>> equality, which does not preserve address dependencies and = allows the >>>>>>> following misordering speculations: >>>>>>>=20 >>>>>>> - If @b is a constant, the compiler can issue the loads which = depend >>>>>>> on @a before loading @a. >>>>>>> - If @b is a register populated by a prior load, weakly-ordered >>>>>>> CPUs can speculate loads which depend on @a before loading @a. >>>>>>=20 >>>>>> It shouldn't matter whether @a and @b are constants, registers, = or >>>>>> anything else. All that matters is that the compiler uses the = wrong >>>>>> one, which allows weakly ordered CPUs to speculate loads you = wouldn't >>>>>> expect it to, based on the source code alone. >>>>>=20 >>>>> I only partially agree here. >>>>>=20 >>>>> On weakly-ordered architectures, indeed we don't care whether the >>>>> issue is caused by the compiler reordering the code (constant) >>>>> or the CPU speculating the load (registers). >>>>>=20 >>>>> However, on strongly-ordered architectures, AFAIU, only the = constant >>>>> case is problematic (compiler reordering the dependent load), = because >>>> I thought you were trying to prevent the compiler from using one = pointer >>>> instead of the other, not trying to prevent it from reordering = anything. >>>> Isn't this the point the documentation wants to get across when it = says >>>> that comparing pointers can be dangerous? >>>=20 >>> The motivation for introducing ptr_eq() is indeed because the >>> compiler barrier is not sufficient to prevent the compiler from >>> using one pointer instead of the other. >>=20 >> barrier_data(&b) prevents that. >>=20 >=20 > It prevents that because it acts as barrier() + OPTIMIZER_HIDE_VAR(b). > I don=E2=80=99t see much value of using that since we can resolve the = problem > with OPTIMIZER_HIDE_VAR() alone. Yeah, barrier_data generates more instructions. >=20 > Regards, > Boqun >=20 >>>=20 >>> But it turns out that ptr_eq() is also a good tool to prevent the >>> compiler from reordering loads in case where the comparison is >>> done against a constant. >>>=20 >>>>> CPU speculating the loads across the control dependency is not an >>>>> issue. >>>>>=20 >>>>> So am I tempted to keep examples that clearly state whether >>>>> the issue is caused by compiler reordering instructions, or by >>>>> CPU speculation. >>>> Isn't it true that on strongly ordered CPUs, a compiler barrier is >>>> sufficient to prevent the rcu_dereference() problem? So the whole = idea >>>> behind ptr_eq() is that it prevents the problem on all CPUs. >>>=20 >>> Correct. But given that we have ptr_eq(), it's good to show how it >>> equally prevents the compiler from reordering address-dependent = loads >>> (comparison with constant) *and* prevents the compiler from using >>> one pointer rather than the other (comparison between two = non-constant >>> pointers) which affects speculation on weakly-ordered CPUs. >>>=20 >>>> You can make your examples as specific as you like, but the fact = remains >>>> that ptr_eq() is meant to prevent situations where both: >>>> The compiler uses the wrong pointer for a load, and >>>> The CPU performs the load earlier than you want. >>>> If either one of those doesn't hold then the problem won't arise. >>>=20 >>> Correct. >>>=20 >>> Thanks, >>>=20 >>> Mathieu >>>=20 >>>=20 >>> --=20 >>> Mathieu Desnoyers >>> EfficiOS Inc. >>> https://www.efficios.com