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 E33A1CF6491 for ; Sat, 28 Sep 2024 22:10:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 490BE6B0282; Sat, 28 Sep 2024 18:10:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 419988D0001; Sat, 28 Sep 2024 18:10:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 244A56B0284; Sat, 28 Sep 2024 18:10:44 -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 F03B56B0282 for ; Sat, 28 Sep 2024 18:10:43 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5462C121878 for ; Sat, 28 Sep 2024 22:10:43 +0000 (UTC) X-FDA: 82615542366.21.628247D Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf01.hostedemail.com (Postfix) with ESMTP id 733324000A for ; Sat, 28 Sep 2024 22:10:41 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kZN86DjG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727561340; a=rsa-sha256; cv=none; b=1btvzeDqAdze4zTtefMVyY9lg8wZ2e+GdAk3fba5AvvY1vdzAI/ux5hlMBVKuP3o6cyy1O 6Tfh2BTmoToPNZuXNGjSIXHK1dGJdvGLG67IaX2ZQVfndFMZB3td8x50tw9jsvT/vnQ8uz LdwZvb70EeYCKWGJ1LsMKw2J7X9KngU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kZN86DjG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727561340; 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=lqv6uZtvWgufJBQFjoO2lvT5jL4vVi5PDl7zOSvVCAI=; b=LNeim16DjaHf3257ve+vYNZzXyF4AP5TajrtIFhFOvc35OtpOLcOtazjFZYQfvgdnrAWpg RN5RHm73mSXTXadziPV/WRP5bk5hUATch6S7x3BLmB4iXVyHVt0gIlvYz1H+r9PMWGsM1o OylGH3poIQVby/rZ5TMBYT69THckVzU= Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-718da0821cbso2551810b3a.0 for ; Sat, 28 Sep 2024 15:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727561440; x=1728166240; 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=lqv6uZtvWgufJBQFjoO2lvT5jL4vVi5PDl7zOSvVCAI=; b=kZN86DjGg+jzQMoDlHKgA6zNzQuhG/e6xReCfttv5U/YVTti/BPWYAHgQoNr8d9EOt 5LbPL0V5vaEiN2V1+UyZ7NL8XpeV1P+0ZZyHYGdZm9aigFqWK0OuGdw26YpBic0xQLTX J/LsHQCaE/oECr5IYq1hJYO5hphM/wsYpc50tVzrC/67+y6CulqWJm1T0obFgE9MLIQI M1ZTtf1PFgEMZHYgiWWPAvwZW02PrMQ9S6le/xQAY1s0wyp8kzZXEdgSjMdnIERYnKgK 6qfYMeHXf2q0rvybwG1wvr4ciRAeIPvLPDhR/KIaA+4k2d4GjzlFFSvVjeUlfCUERvYT aZRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727561440; x=1728166240; 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=lqv6uZtvWgufJBQFjoO2lvT5jL4vVi5PDl7zOSvVCAI=; b=sBHdPmSeL1Uektvk3SjCniDsNsgrL76A4LKRhAzBkTRQPph1BMJHpd9W/YAwn9q5b2 IOShoGm9UQ0RKcje42eh/Eqf/Qo+HMWg4d6WB/6PArpSfhbjf6s5398jxu/1seSo5Rpd jTVgWe/dihPgIU0GNrInzw/t2KT7m8a0G11hppSFQnmkTeN0DENhtRGS4qi1NSpTAhqI ERKorUrKdG14y3qrjhy1WijTFmDnR8BFzKi5OzAAGOCBT7yLk/GbsOdGCjNrCEuwBn7C cgs4k9mylSU3pcNY8fw12mLKM0fsBQjeTp2dxmXzyYQDewdx2e6KfwAdhtiMj7uBw1vc A9Nw== X-Forwarded-Encrypted: i=1; AJvYcCV3b7AnCMvlrsvXy/NYFo0KFwlwIx5NcdQvrA1Saa6gtHIf97OUUKwhXzSnkBhUxtLOffJ8egRjDQ==@kvack.org X-Gm-Message-State: AOJu0YwClaadGjhY9TvyWWWoXPg9VtfNx3QgF8kzrepvu6Llv+Kd1TJp VvMhjwbILr70IGqjk/tgwE0qycqOZeHCFjdV3PEyRJqb8BckPDMx X-Google-Smtp-Source: AGHT+IFhovJoNYleXxjXLz6aGvITgc6JOAD0PX6lEgltW3VQ1SR5GvjGyJEZPadxx0f45FlXPLeQ4g== X-Received: by 2002:a05:6a21:a247:b0:1d5:10d7:2020 with SMTP id adf61e73a8af0-1d510d72090mr2118216637.41.1727561440019; Sat, 28 Sep 2024 15:10:40 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71b26538828sm3592306b3a.219.2024.09.28.15.10.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Sep 2024 15:10:39 -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: <4ed833df-54e6-454a-ab1a-73967cc51054@huaweicloud.com> Date: Sun, 29 Sep 2024 06:10:21 +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: <5F741990-7A14-4528-9AF8-817007689B0A@gmail.com> 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> To: Jonas Oberhauser X-Mailer: Apple Mail (2.3776.700.51) X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 733324000A X-Stat-Signature: okacgkbay43fqybfzd1tmjq7rzhsqfrc X-Rspam-User: X-HE-Tag: 1727561441-783438 X-HE-Meta: U2FsdGVkX18njF6RMc2u0m0xJSRPHGNZuCFy8iwRXz06UeSk0o2YyNNkXdTdRWTsNbQ6sf2pV//gXdlUbvudvJwRcH5E2PW7wZsE3sBy+cxK/brrXzmBfi0n/Ft5RLf2vUm1uXX/ks8sByS6z7EdubYVhhSAy3UpNQCtdqPGqJFl+55XxXnsTTd6J4X+GILZ5zfp7P8cJdWRwLDMXED4g3+2x7aFTJdzMmijcm7RA0bW3+R1xOqld6pOQBC3CsmZt872uaR60rQrnVIg1bp5G155ZAIcHkI7G18Qvek4cRn+op9KnOgbDOer9ZohtX1h0NETEOS2zbVNIP9Z6IYoVtYtCBMpurLB83UB9gfM0MOk6h3HXAqdh1BymjUh2un70U3tjXPwN9SNRleDImQ4MVO90JQFOZ3snEYHkilzHCTL47R323Yq3jvSE+fAAvx3HxeT4k7bnnLHmOznyCcuq23mkRJ5zEMPzhXTk0+1c3aZRbHgfzPT+TQMaMnu9rSHIYRQjO6Qcrol6bsK9R7/GFb72CiLI9p7ZA+QbDxj/cqLbtyb9k2e5jZe9X/ddMOEXS8TYMto4LsUJ/4jIm3me5q32cAqgaGM0sQW3JjxFpOWqFfAHqL4fOT20QOc618wd6Ko+NaM4wShfHEaBEvJBzKWoWEwBXnktqgE19ucRWx3OfdfHfT54IvDfqolNMmdNYAIQxIjEICq1RaQJJw2TbmFILMWnKUt00GeAC8CpTW5p4zkSLLVdccVLCSsq4KGh/nH06BkJgx7N0P3jyqZtxmCW4IJ35EWcTPibcoXjdyyPRrTocD74imfEcpjqa9yr68baL6YGlvRgbAcG0ZleZQLDda953vscno9kVU5/XO6lRdvevDkP/9B8PvFk333eZNkWGN6/touuAsWvx1lVZOoDUeXClVKrQA90tS0izDUc8+6zTUNRYyA1uVDc5zVXiLcT2zeZnyWRWwv4rZ 2zyw51Ai dXvEHm3r+jWLd6evb3hCXjruuXoObsotOYDHx355uZHM8rugqpk1bytxq7vPcg2TI7nTJCtkikc6Edqs6oAoutV0H21MWm6pAQrKH0YI9INwn/ewTbYL5E55YDsVcsjEe4sjgmPYovrFrzVWC3hUUorH+Xl8uaydc3mGAxaLb7Vgrz/gBCJnILcQ6+Da8NjOQe7K421nO4NdneI3E3zfPKJfS7Ki94xA/tqastR35oyt/bV4XzgG+h0727LBxTRH4QmETw9Ll1To9igHnekIcjFWBsHrwPldllRPXnWZSqIeB7rirQ9XfRkPZKeSQxB78et9lp6dkg4RrMzNsUBZ+4WqqDvKx06zuoZ9X5DQ/qw8u9Js71KYTZtjt0QPXkPtgbfCvASgPuGTHZ12Ow9H02XQB6yeoR7g177B3cI9gnZJ1F+KB4Aka0mGUR+77dX74iTEbfF9SEaVf1NXAJxPS8CKwpTZuQ1FZ1hODQFvXFdyQeGlwHxWl9UUNEiIsTmBsj+rvJ4qiWPFHk7oANxazCXNdUPHwF3XpQiAlSpoclAqHwGDv60RzLwqSWidfMOOhQcAFFIrAgNWLlzeJwkIyUS4uWpLSFd7SM3U1S0PZSTrCPxX4OmcZDh181Q== 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=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... Let the p to be a static variable out of the function will make a = difference. Or the following: =09 int **p =3D &b; barrier_data(p); also works. BTW, barrier_data(&b) generates more instructions than godbolt when = build the kernel. >=20 > Have fun, > jonas >=20 >=20