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 2A84DCF6497 for ; Mon, 30 Sep 2024 09:28:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A39946B0115; Mon, 30 Sep 2024 05:28:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EB1880017; Mon, 30 Sep 2024 05:28:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 863446B0119; Mon, 30 Sep 2024 05:28:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 65CED6B0115 for ; Mon, 30 Sep 2024 05:28:08 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0795D80847 for ; Mon, 30 Sep 2024 09:28:08 +0000 (UTC) X-FDA: 82620878256.15.4D64973 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf29.hostedemail.com (Postfix) with ESMTP id 24BEC120007 for ; Mon, 30 Sep 2024 09:28:05 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="h5ny+go/"; spf=pass (imf29.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727688422; a=rsa-sha256; cv=none; b=QGMidMHn2Temj98DP80z7lbetLembugtD1mE2U1AfpovpNFbufL0OMaZ9nbHaVXiM8FFbJ ricVH/EA+nwzXgAKCmvrpfLk3ioytR+0CKrtmpZeOd/h+Jmx1J7lWCxXpi5KuucM++8kfF 8cNNaIYX3C6aLORuRC0tsBE3RPyUIVw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="h5ny+go/"; spf=pass (imf29.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.216.42 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=1727688422; 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=z059m6JExv5qpwK4TrSHM55XYy4d2Mm8ALddHKMFxag=; b=c1t/KrVNoBdxW6rFTAks9mgAa2BSWPcQMZc5V17ElyGY8stzsDpJsFd3R6vHogETgqA/05 BNoVSsMA4KYPYKbxu8rS+Kn4FAZVltMDdhr0uC0USMkPb4rged/OVJSfhnzTwCoJ80FwXG 0FO0194ZWs6boV6rY9bFmRGJm+zDF3A= Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-2e09d9f2021so2673505a91.0 for ; Mon, 30 Sep 2024 02:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727688485; x=1728293285; 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=z059m6JExv5qpwK4TrSHM55XYy4d2Mm8ALddHKMFxag=; b=h5ny+go/Raw4Sp+3FLKE9nFMF65XI/Nmx65vretlNohXxOol+4MIpdjZjeO2XmzWup 2q44vre9+1Jusn2bzBulo7bCDZgKwsSu0IwRoJgnRzcMycAhAvXj8UYxQFUF860ZTPf8 LfdSbftJ2ZmKSjqHDYG7om7csxtWBhU+e0GnkKEZGehltZPdnPa1PiYgKwIc9AUnn3bc 2p83YdrgHDdc5Nij4fwpLjJSy8v0HEJ0aD6eUiMX6nfphnQsQdAEPr6DbHhiXTRRN0Bv CbVRVMS/63g7viP1uk0I28UcFZV9WOEbHwyBadFSYiTmSkyXBHPHpEwYWpthaRFBCt9E d2SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727688485; x=1728293285; 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=z059m6JExv5qpwK4TrSHM55XYy4d2Mm8ALddHKMFxag=; b=kLyEqcJHtIBxJBBnzRfyIZUxACctbWwrjF7QdNFSA+MaIvFP7fjlXFkJ7oWxPHcRkY F/fLM1jiWuw59LO23uEXGoAw4lPfvy0L7j5md4U38Q1mkeWHMhFPsmvQeNU6VbIscs1c KKsNHPDjWb2nVfRlliAgnJo4npCyd2g+qEkS06ZdZj9wzYJmMiuZBOl1OEU3axv7xoA+ b9ONT3wFSDV3i4xKqx6/JsB79K5Slzr5c6HKrDNXAvqEz+WH9pNB41dVx73Dvng8+rqm zcLvumJR7uabJkYB5gMCuT3xt12ZF5slDcLAOE7ZzhuoYaVegvtlHCz7C1l/RretRPP+ 2U0A== X-Forwarded-Encrypted: i=1; AJvYcCWcabrruGqJnjtMn1uSNRXuLC73+0i4LJ3YGawqxVFjQ8QBOFXb4ujMYZ+7Q1yu2CRkGSZ1G7f3Wg==@kvack.org X-Gm-Message-State: AOJu0YzbxZNys7BjC6OhdtvpEgwHAEATfNt+rb6HiwfwqL2Bem5cWe9u 1nU/qTuosAzDyqLxOt66/z/s3QpfwXbZTPW++OsQVuWNcUAsNGL9 X-Google-Smtp-Source: AGHT+IFEpUA9lBz28DWCV9NGf0oBtIqIPy4MpNVYCvzKykDQJRwefTC7jlNkxWq5imCATpncdx/8Kg== X-Received: by 2002:a17:90a:a58e:b0:2e0:808f:ef9e with SMTP id 98e67ed59e1d1-2e0b8ec8cebmr13138814a91.26.1727688484625; Mon, 30 Sep 2024 02:28:04 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e05b57decdsm13371449a91.1.2024.09.30.02.27.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Sep 2024 02:28:04 -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: Date: Mon, 30 Sep 2024 17:27:45 +0800 Cc: Mathieu Desnoyers , Alan Stern , Linus Torvalds , LKML , Greg Kroah-Hartman , Sebastian Andrzej Siewior , "Paul E. McKenney" , Will Deacon , Peter Zijlstra , Boqun Feng , John Stultz , Neeraj upadhyay , Frederic Weisbecker , Joel Fernandes , Josh Triplett , "Uladzislau Rezki (Sony)" , Steven Rostedt , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , Mark Rutland , Thomas Gleixner , Vlastimil Babka , maged.michael@gmail.com, Mateusz Guzik , Gary Guo , 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> <8d20cf79-9fa5-4ced-aa91-232ccd545b59@huaweicloud.com> To: Jonas Oberhauser X-Mailer: Apple Mail (2.3776.700.51) X-Stat-Signature: qs4df9buk7zmj6k4bng6k83s3hgdmjka X-Rspamd-Queue-Id: 24BEC120007 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727688485-340111 X-HE-Meta: U2FsdGVkX199RdnK6QnJ7ASfsLBhv7R/gtfNjGX6d2OdE/6WBO1lELq6J00D7emy59NJZCrSOM4hk2ge+xNGX2L7eF/xYuQfa+Mx/PBC0FKiWB2E7DP84CBrLkkE3rUgpjlnS3NY+y9e7CMY3ap3Einx37uN2vGKmqvI4j0rfRDca7jyPxmzf2ZM3Rp5uwet+g4SddBLJ3sBbCuUKQg2/vYi8Gwe6D7N1Ym9xLpqXRustoyXrJy36m9I1C4xgmpw/q1Tic6RPOm5B59E081qiDgabLxNsBYsWnl+qCc+irwLIBgxlh9mQEWMfp/hj4r1BK13rsuPgZ91bOeTX8SZd3l/vLuRPfKxeQSTs8FjkzVMLJproCbDGH1yi94c9OrmkI6CapxXGswnFUUtPE7S3ZxJhA+izsS0nH9hFS3NGfe2iDYVw7jiyPeXSRUI8+nFQ1Fa7XjcJN506iEaBK4DbR9KbVbuMkLVKfkohKUm4/qf5TkWW1p5nFMGIs2SlW+vt6CqKTre79gxHcz1o53QIHqNBJvOK50cQpG8ThhJkDcHClVjujYR0N9pbRcdhbOPoUbpZDq6NCU8TEEGG5Qt5lA4ttdg7bawiqPxFe/J9Y5qq1TmipcXMzeatLnV6z8bKA2PC1q2Pssw1elxZpr5O5MHV6+VsLVG/Owal/nCYCKeBdw/aqAC5+k0mKPqhWZjYHf5P1rG4Om/p93gGBuSaWNDfZOdL3YyOnI0dMkJ+OdnKk3nBXS7ZSrwl7ULPdDj+FwbBskN98Yu12TsR21jdkIRppAgG3+5W2mf1NW7m2L9Vg0Nb2gN5D6r3cLpVxCNxCjUbc+d1ubyTH8o7sTve5bqsuQM4SD4orkjWmHKU5OB4+zqDvjuYt0LWDx6s0ScTKWhjTMdJBjveGlWjSTUEgHNjHlJ5QLZj2A/aFZLBwSVjvB0IFZ2A4BbLOnc7EQZ3lfnFUDxrT68+MaQUvO v+yNYOWc WW+El9yJhDBmZryaJwjYG/H0ohBPwzH2aB1DG9v8hczNnfLtS161BkepzjlTmz/XNHtpr4jj0wNavs3roOMJVmkAWl0IAaUOFNHaKfT8Ujkr5g/5j+ZKKYJ/VdSd5gVbWJXI961uqec4CrYHsEf5y6RdM6sNJfYie/+WR+uZ5BYCoE5tQs5XsrwHGbuopl3vwpCYdgvmN8dTOJGFGEEBbovlH9G3HbDaVVec5P+MwEnR5AABzCilqMexOAYAEpypcBUz3ZNrV/V2Y3ZAblzpTJMDKvV0Tnd7XLAZkgNHpeilUzvvZEDvg49sSUBLLkCSoG/KubF+6NwYdArnpEN3+P7NQguEQ7oy8tL6MWQQMaQeWU8AEH+WwPdEvPrUDDDz2p48K8qTn8/K0IU6gbJEZ183E4Zc7z3XzGuXnETFN0JUtlAx2k8ZEvVshAjd+lGVHxXsf8IVSfwAp3U5OdOFb8oEoclM4VsNOoTrvz8+1dWyX1xy8U/PLAomum+MuHKfW0rNqM5+UMrYsHnZvGqjAUauttQS55G9hjlH6/y/pX5jwNtpf0VEx8H703pmCb8GYRCXltTFJWqdRqhbp7ozg3iyyB3JI5/DHxcH3FLKtlgMAnYzfXCWJW64os+Roy3DcI28o2jtPztfHMK/eFL2BLc20jA== 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=8830=E6=97=A5 17:15=EF=BC=8CAlan Huang = =E5=86=99=E9=81=93=EF=BC=9A >=20 > 2024=E5=B9=B49=E6=9C=8830=E6=97=A5 16:57=EF=BC=8CJonas Oberhauser = =E5=86=99=E9=81=93=EF=BC=9A >>=20 >>=20 >>=20 >> Am 9/29/2024 um 12:26 AM schrieb Alan Huang: >>> 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. >>> barrier_data(&b) prevents that. >>=20 >> I don't think one barrier_data can garantuee preventing this, because = right after doing the comparison, the compiler still could do b=3Da. >>=20 >> In that case you would be guaranteed to use the value in b, but that = value is not the value loaded into b originally but rather the value = loaded into a, and hence your address dependency goes to the wrong load = still. >=20 > After barrier_data(&b), *b will be loaded from memory, you mean even = if *b is loaded from memory, the address dependency goes to the wrong = load still? Sorry, *b should b. >=20 >>=20 >> However, doing >>=20 >> barrier_data(&b); >> if (a =3D=3D b) { >> barrier(); >> foo(*b); >> } >>=20 >> might maybe prevent it, because after the address of b is escaped, = the compiler might no longer be allowed to just do b=3Da;, but I'm not = sure if that is completely correct, since the compiler knows b=3D=3Da = and no other thread can be concurrently modifying a or b. Therefore, = given that the compiler knows the hardware, it might know that assigning = b=3Da would not cause any race-related issues even if another thread = was reading b concurrently. >>=20 >> Finally, it may be only a combination of barrier_data and making b = volatile could be guaranteed to solve the issue, but the code will be = very obscure compared to using ptr_eq. >>=20 >> jonas