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 8F755CF6491 for ; Sat, 28 Sep 2024 23:13:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3AB36B00FB; Sat, 28 Sep 2024 19:13:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEA146B00FD; Sat, 28 Sep 2024 19:13:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB2AF8D0001; Sat, 28 Sep 2024 19:13:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AD8DE6B00FB for ; Sat, 28 Sep 2024 19:13:16 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0D3194108F for ; Sat, 28 Sep 2024 23:13:16 +0000 (UTC) X-FDA: 82615699992.02.247333F Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf20.hostedemail.com (Postfix) with ESMTP id 36F5D1C0008 for ; Sat, 28 Sep 2024 23:13:14 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EUJOdL+y; spf=pass (imf20.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.214.172 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=1727565130; a=rsa-sha256; cv=none; b=V6FBbhwMQrwGui8ueUXQVQJq+PN+MxHZPNLBXCMiaC8vDSjVA1iRurLTaHWSvrYZeqGeFp TC520Nu4sl3pebsa3flB6ue7TbVVC6oQ/2GnHdh5K9tSqKDDwqd+flZFT2rF+qEkcJDqig bEcjsp54V0yx0eQ33kllzUH4orsQvxE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EUJOdL+y; spf=pass (imf20.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.214.172 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=1727565130; 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=hlXRms7F/yIYEZIpY96anVWqMAu7/hjyZTvOiryivSE=; b=R5uqIu1F+59Qm33ADmEgDsbVDK0N7eeRwftrR50iJ/yq64u09J1MTD0QE/sY7Ji9ZjN8vB trfT6MvwAB/9B4tjimGGFYUTb4jeAtNqvJfdtI8iGdQjFpcUA961cxwO4+0fCf9PLIUB02 tpJAsp1BLifwyZJXkrylN0AAMhRMX8M= Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-20551eeba95so31950855ad.2 for ; Sat, 28 Sep 2024 16:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727565193; x=1728169993; 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=hlXRms7F/yIYEZIpY96anVWqMAu7/hjyZTvOiryivSE=; b=EUJOdL+yI0s+j61JaoQnv6L8pe+nRj0zOgHD39GdZbcl/Vtcbt4mHdTXBksSQMklZ7 Qt8e6u+Sc0eaj/S15PCuTzeyjF9mtl4KUAuZVvBMzthstB2qVH/UcR1h8SILFfAcp06T n5Enn0t/LSNTgFDHfHV/SpIkN5h9GaDCCUhN242Hw+p3C4tHZNNwCP+oO9uu3uDUQAHl PbPVJO4t36gbgaewQ1HR1OTxu6PmVq5qVdQaAk2EMEemlvjD4nj5t2Mvkoj8zcujaUqI 32N9v9/Mjj2U0JpvbLm3yRWWzgydAOoOR34XINrMKnNf5noBx1XTSezB8ZSYI13Wz2Jq MWFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727565193; x=1728169993; 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=hlXRms7F/yIYEZIpY96anVWqMAu7/hjyZTvOiryivSE=; b=d+ozDBlX5nmXDWdwRXb+iXlUvOj2+RGGxaEZOpYPmn1uibotgTt8bqnKWwa8kislOr sFv2+rpGwuiMXRM3dOJr09ODb6Xl4mQnEM8iWx+lrr86aXFnjyI5ZWW7jec5MZ1Dv6D+ 2j2rzjsx4LNy06175qrrXUmHh5Qa3Rw+R8on9eAwQBNlSA8E1tohqWemg/66mJq5f+QQ MbpMj4cemCiDCXNK1Gpo+63D3kIDBdixTI/v82lFWJmiNc+4sthg/icd1ZaIhz+PbLZ4 gtetU5MWKI1V7UTK39CpICw3+HKfZ7EQcJUES/RLFGLG9mSNfA0PEz9jb5SoTPYk5Kwy nPfA== X-Forwarded-Encrypted: i=1; AJvYcCUR945zlFQDWumZBytMuRo99K/iWtbaEyHuGMVQOztsJKHXP5nFNlYh34fS1JW235X8TOj6nZoJAA==@kvack.org X-Gm-Message-State: AOJu0Yzghdzh6yJ/CNmlLQR2RQHh7cJOlOssScogfcYb23G+KOk7TA0Y r0ZjCA9ounYPgIylR0XKLGvoQyvgsGIBltDG8hjLCNpfdiRvBg7ZXcm2IPO9 X-Google-Smtp-Source: AGHT+IE2sBYP1tAvZqMQRpXmx8wMXmRsA3LnUmxXborZPEfW+jZDkloOvwEfncz/nFiCQJfXofJTmQ== X-Received: by 2002:a17:902:d4c3:b0:20b:7731:e3f8 with SMTP id d9443c01a7336-20b7731e676mr1645985ad.26.1727565192698; Sat, 28 Sep 2024 16:13:12 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20b37e0fa94sm31491515ad.135.2024.09.28.16.13.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Sep 2024 16:13:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers From: Alan Huang In-Reply-To: <5F741990-7A14-4528-9AF8-817007689B0A@gmail.com> Date: Sun, 29 Sep 2024 07:12:53 +0800 Cc: Mathieu Desnoyers , Boqun Feng , Linus Torvalds , LKML , RCU , linux-mm@kvack.org, lkmm@lists.linux.dev, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , "Uladzislau Rezki (Sony)" , Steven Rostedt , Lai Jiangshan , Zqiang , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Mark Rutland , Thomas Gleixner , Kent Overstreet , Vlastimil Babka , maged.michael@gmail.com, Neeraj upadhyay Content-Transfer-Encoding: quoted-printable Message-Id: References: <4167e6f5-4ff9-4aaa-915e-c1e692ac785a@efficios.com> <48992c9f-6c61-4716-977c-66e946adb399@efficios.com> <2b2aea37-06fe-40cb-8458-9408406ebda6@efficios.com> <55633835-242c-4d7f-875b-24b16f17939c@huaweicloud.com> <62508c1f-66ca-450d-abb6-236ca3b9096d@huaweicloud.com> <4ed833df-54e6-454a-ab1a-73967cc51054@huaweicloud.com> <5F741990-7A14-4528-9AF8-817007689B0A@gmail.com> To: Jonas Oberhauser X-Mailer: Apple Mail (2.3776.700.51) X-Stat-Signature: k8486g77zpfxrgzehptwj8c9qu6mayop X-Rspamd-Queue-Id: 36F5D1C0008 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727565194-19087 X-HE-Meta: U2FsdGVkX1/Cuzo7wuxIrdl/1fB4n6NVV80yF8nggB/fRrODuyeleZrYL8Kf8aTIPa4gMJbQspLFv+VmJ99iJzk1V0Y/nBRDdxRqcpgzDBm8J8fUExiNPz6gH5npWn7ykjMu5PDSsxGgALi7wnJESeyyIQ4ZdpEvOVN3FNczQFEYBNe235VzePe10tTSYIksphU5fI0Nf+p2GCfhi2c03+VBwXHzzHazuwt6Y+e8lEP2hTN24HvllTPh9/418+EIhYgDgseAzwhs7fSgMRPO1nOAdKBrSIAjZY5JHf9vIth2UBFcZT+aIs/5OG6PGyek1ILAuGSNrbcoMkqAkrZuVYqlB3aPK9EqOkVITPWW/jat627TsO4/TCHL2jlIYUybM1G/CbpSsDMGne4dLq5MMYXvAT7o9Bv+E/SqRA6WP8GXqBJpauk92H5Hb54nw3y4KOvb+owHOdwgOA0uLYc9oFoo7sGH4ZBEFT1aAWDuNGDC9mlIb/aTgLeT/QC7JwyX/OnntBvXcbTXt5LSji2o9tPhkDEMZyySGuzY2g4H4S3ATxldwOLocU6CMdDZ66lH3hSrtSm2aQSj6vZaliEyTmUl+mxSPvvCODWXoqRwdXin7e5r2dgAmFEeE9TCeUmOxFkXvsdhJCZkftGnd4YPmlCQpRbVwWc2YNSNjF9NWpFIDWn8pR96EONk6LvS0ed9nBITIW4/5fy4ni24MptPwrHnlm1KQJWmw1RnUZ8F4+/Z6n2NVfgl4BF1+yHw3/k/kU2i/oJoOOGluQFpqOX9ehXcK57zCw2JljriIj/KxDa8QUV9UqDaS5gqwqW27zHVUNpwhFme90QMlUrwoI34BPCKVI8i3BsBEyoMdYoX8TWxLehnrGh34cweRTEfUJ9oeBK4ToEL5wP12U3E8vjW9wS9Jk59cCJv/QjqMVg2fJBgrg13AHp2dgTLOSDo8PgLIKXViwViGboApCySPKZ nXR3wmUM shlDlvkA4iuWuNYJMDh3b23/oTznwNwpGcJIHyjYmPkGi9/nkeOLzJIsRjnVhLUqKnky4DOafFSiSO936iVbmyezb0J7QuzJvGc+Lp9G+JeDGjqohvxmExsuKnJXfDoEI2brliF5BD8ZS7ZmlWGXOg20Q1D0e344bOStBy3s9+nVoFp6yxXBk+48o2+P6mRJLK465epbOFZ3JqebQhuFkKo/fB4zAZN+AvYY/KFnyW43P6zEUdmjZ1vhORnyhz0vwTj0EajnxaGDY9rxCSpDSH78OSe0h/174s7s8JGaWN5Z3xDlDP7PgbIOPM/iXCCIHxgZEPk/t35M85zwi82y3G03FoTAYbu245q4ZHRwPnblRhoBiDBO91qcyLUn6deu0u6wDY1KVQmRvHy/XTwuTuY6CtUcpYMD8pZUBaK8/QHhwbDcV6WlZ9MsUW5neQCibarCEONptQnqCsVZtLhQ4ohTrRk0ONR/2fYDyXpW5esZxUfDx+HS3ZQO+jG0MET8Rh/GNnkDH4UmnCv9ZwuvhJkkwZHVw0Sw4AKmKPxS1yiq/J7I4tdRilE5/3ZOWYp8K2MijEDdfXKGxfdHfKlpQLtNj/wUBXc/FFx/I 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 06:10=EF=BC=8CAlan Huang = wrote=EF=BC=9A >=20 > 2024=E5=B9=B49=E6=9C=8828=E6=97=A5 06:18=EF=BC=8CJonas Oberhauser = wrote=EF=BC=9A >>=20 >>=20 >>=20 >> Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers: >>> On 2024-09-27 21:23, Jonas Oberhauser wrote: >>> [...] >>>> That idea seems to be confirmed by this (atrocious, not to be = copied!) example: >>>>=20 >>>> int fct_escape_address_of_b(void) >>>> { >>>> int *a, *b; >>>>=20 >>>> do { >>>> a =3D READ_ONCE(p); >>>> asm volatile ("" : : : "memory"); >>>> b =3D READ_ONCE(p); >>>> } while (a !=3D b); >>>>=20 >>>> // really really hide b >>>> int **p =3D &b; >>>> OPTIMIZER_HIDE_VAR(p); >>>>=20 >>>> asm volatile ("" : : : "memory"); >>>> return *b; >>>> } >>>>=20 >>>> This also does not generate any additional instructions, unlike = just using OPTIMIZER_HIDE_VAR(b). >>>>=20 >>>> What is the advantage of defining OPTIMIZE_HIDE_VAR the way it = currently works instead of like above? >>> Did you try it on godbolt.org ? Does it have the intended effect ? >>=20 >> I certainly did try and certainly read it as having the intended = effect, otherwise I wouldn't have written that it seems confirmed. >>=20 >> However, just because my eyes read it doesn't mean that's what = happened, and even if it happened doesn't mean that it is guaranteed to = happen. >>=20 >>> By the looks of it, you're just creating another version of @b = called >>> "p", which is then never used and would be discarded by further >>> optimization. > >>> I'm unsure what you are trying to achieve here. >>=20 >> Simply put I'm trying to let the compiler think that I leaked the = address of b. After that, the memory barrier should let it think that = the b after the memory barrier might not be the same as the one before = it (which was equal to a), forcing it to read from b. >>=20 >> However, I suppose on second thought that that might not be enough, = because the compiler could still simply do b =3D a right after exiting = the while loop. >>=20 >> And that is true no matter what we put behind the while loop or = before the condition, as long as the condition compares a and b, right = after it the compiler can do b =3D a. Just took me a while to see :)) >>=20 >> I'm not sure why gcc does the b=3Da with the normal = OPTIMIZER_HIDE_VAR but (as far as I read the code) doesn't do it with = the above. Maybe just a weird corner case... >=20 > Let the p to be a static variable out of the function will make a = difference. >=20 > Or the following: >=20 > int **p =3D &b; > barrier_data(p); Or the following: int **t =3D &b; WRITE_ONCE(t, &b); barrier(); return *b; also works. >=20 > also works. >=20 > BTW, barrier_data(&b) generates more instructions than godbolt when = build the kernel. >=20 >>=20 >> Have fun, >> jonas