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 55D0CCEBF76 for ; Fri, 27 Sep 2024 04:39:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C579C6B00A7; Fri, 27 Sep 2024 00:39:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C07F56B00A8; Fri, 27 Sep 2024 00:39:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A813A6B00A9; Fri, 27 Sep 2024 00:39:29 -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 87CEC6B00A7 for ; Fri, 27 Sep 2024 00:39:29 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2ECCC1A08F3 for ; Fri, 27 Sep 2024 04:39:29 +0000 (UTC) X-FDA: 82609264458.23.96F818A Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf04.hostedemail.com (Postfix) with ESMTP id 057EF40004 for ; Fri, 27 Sep 2024 04:39:26 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mKxvXNz9; spf=pass (imf04.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=boqun.feng@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=1727411844; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dRU6/4TVUAhjoio/t/k6qqSqdEw/5cr8n1FQhHvr5Jw=; b=QqObkzzQOkMutMAOOFTHF9siXVsvz2Og49BK9TQLHNUk87mU6ZrC/d9WpgTwfzQ1IW/6yr JX4cCBorgVcY4JHGWTssGaqY95HhxUwLqwLwJEKCC8fJiDgHXbbdONQHMyJ2RtOhEe0RUP rgmIJpd7pt0q9EmXR1ZFYN4LwQ7AS4s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727411844; a=rsa-sha256; cv=none; b=7tsHwSgmAODo4CHrOpZFev2Wu/wmfzRLg8y5MxFCCJQ4AuXGDpoBKZcWonVmCn4Pnqm8/u t6/B6PKnnbxSlYzy5Q/2VlkWuohC/Aa7g3r+lP77H7ucb24sm2/ui588T65DtzFgdmmBmw FyLpJafaD1kBMY/oh90v2r2xzrU+C6Q= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mKxvXNz9; spf=pass (imf04.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-45aeed46f5eso7519651cf.3 for ; Thu, 26 Sep 2024 21:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727411966; x=1728016766; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=dRU6/4TVUAhjoio/t/k6qqSqdEw/5cr8n1FQhHvr5Jw=; b=mKxvXNz9PBhipWIXTF2kpLbqq3/UaL6QJCu5IxF1t8Ais/RMV6h915To1wxSgEl/U7 UhVvMC5xIOKmzMxUbMi0opcZ0q6eET1MbXmWmPX5kEo6Emcd9Q/PkfED6P+HXtGC74Aq TJktAt8C8sd6bP6miVUobivp5wRI70cAatCKzGEHjmMPWELsZbMN0Xu9Hcm9eLOA9JGV nLMEvztGcUCP/PfzaHikwio2BAibHDUU/3i+vblGD94HyBqf97r0rygJjkeLh86E33Xr j943S94Z7zhDc/JlpMbEXIiMnnu+kNeCiBp2L+g2RjW3Cx/bIURLRldTcGE11jTe2kv1 oQUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727411966; x=1728016766; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dRU6/4TVUAhjoio/t/k6qqSqdEw/5cr8n1FQhHvr5Jw=; b=sQ8e1yJzO9TA4ddTsKGhgbD1PcUAicOIJZIQx8mJtG8Y9MwBRi5CPciOG2YXBJ9FU0 ef0Pnt4VCNT5/CK7gZzpKUsQ2D26IMsblhXw0klNxSJJ6gs9ElVslLrgKojUIrnsMGp1 JkSxyGCcMSCVdOphlGVLpCIGCU21VFGDBa9EJCpa6wFmR5xuEs296htYTzI8o61H1Hop jp3G3E3dd29FmLxks4cJiBMkSOOfyHPDFCXD/JbKHx6iAYA4UR9A6Usl0vBkY3wpqgZn MHljVAwYNsZ9HaEL7AyqzwGXkgdBgKeyKo5QUku3mAdBSgvYw7q2DPOAUw8luHZno9KQ E6LQ== X-Forwarded-Encrypted: i=1; AJvYcCUOPrfWigQT2Fq9rgkKzYhvyN115RE+EI2yyPuq0nopmvEB2oDbRPmksM6cUpeB7WP5qLx5f1NlrQ==@kvack.org X-Gm-Message-State: AOJu0YzbO+zp5MNcfLRcW0wQCOSN23/P0iMEIyovhJJjBdj+V+Wd3Ws1 ryhfrxm2CoFoCZRu/UKRuiModeZ6b6Dga2LNQ4DHcrPEJ3xqzTCX X-Google-Smtp-Source: AGHT+IGRJNR8YMG45DUkKzLpm66mQWZjHJK0giSYGof1EtZOJwSea9/ISL5wW4ohXqjOGHnxmP/MAA== X-Received: by 2002:a05:622a:3c6:b0:458:4fe5:b2f7 with SMTP id d75a77b69052e-45c9f1afb2dmr27273301cf.5.1727411965976; Thu, 26 Sep 2024 21:39:25 -0700 (PDT) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-45c9f33a4c9sm4743071cf.73.2024.09.26.21.39.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2024 21:39:25 -0700 (PDT) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id F372C1200043; Fri, 27 Sep 2024 00:39:24 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Fri, 27 Sep 2024 00:39:25 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddtkedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvden ucfhrhhomhepuehoqhhunhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrd gtohhmqeenucggtffrrghtthgvrhhnpeehudfgudffffetuedtvdehueevledvhfelleei vedtgeeuhfegueevieduffeivdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi thihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmh grihhlrdgtohhmsehfihigmhgvrdhnrghmvgdpnhgspghrtghpthhtohepvdejpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopehmrghthhhivghurdguvghsnhhohigvrhhsse gvfhhfihgtihhoshdrtghomhdprhgtphhtthhopehtohhrvhgrlhgusheslhhinhhugidq fhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtohepjhhonhgrshdrohgsvghrhhgruh hsvghrsehhuhgrfigvihgtlhhouhgurdgtohhmpdhrtghpthhtoheplhhinhhugidqkhgv rhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgtuhesvhhgvg hrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhmmheskhhvrggtkhdr ohhrghdprhgtphhtthhopehlkhhmmheslhhishhtshdrlhhinhhugidruggvvhdprhgtph htthhopehprghulhhmtghksehkvghrnhgvlhdrohhrghdprhgtphhtthhopehfrhgvuggv rhhitgeskhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 27 Sep 2024 00:39:24 -0400 (EDT) Date: Thu, 26 Sep 2024 21:38:36 -0700 From: Boqun Feng To: Mathieu Desnoyers Cc: Linus Torvalds , Jonas Oberhauser , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Uladzislau Rezki , 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 Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: iug8m7ig3rryohgck3aj5b1pfkyopzc3 X-Rspamd-Queue-Id: 057EF40004 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727411966-588104 X-HE-Meta: U2FsdGVkX1+tqnr1u80s74GvFI1hwSCY2VjK44LZzGQUtGxnKpnp3T2InGPlu/YUNMcKr3VVsplYfIX1NTRmkidFcQpknm/cIODwXDME9KQISbFK1YvlSe6aGwkVPhIvCAxKqvdwqMVh0zyc4Zz8pq6pCwPUms6Jdb9vhUEoud+/xjZYyPSbLCb3GdRKM1xVpSNeesjj5Qu8KjW5l5Se66DmMsn55Hemdjwvfqbbj+Iyr69p2dyB460VLfh0Ey9ZeQNuQBhe21o3ms+tlk/JsyQ6fwbAqPxIOPy1P9v/wJs9encX5CYKLV3LaBqIglpBNHd5/GmiXDfn9i3+Fjk6b8yYCiZluANVxtI1YLP71NKS2I9OD9li/tzQeDvvcUGJHrzCnrnVffWjQqWCj/xMerbSYF27bBEBH50k3XKBPf/Jix49CN5i7z2nt9KTdoa7Bq9rR/PffeFBBLYmvoax+Rz9n1hohnfYtfKZqXQ1YmiZ8lEvsNcEOi8f60RxhiSZBUDVqs+jFU1scPWs+raOxoC0Ral719fhrIv+sfVYI1ud3ystfDJ5PHvimcd3FT/GU6KUHmGfD9htF5w/isPQEPFb/Ry7/uxm8ZoAovlGZSbjTSWKw+wG9dQUFOcXov7FQVpEaDeZG6y0HjtfoeznoE57T9zlSx9U00+wK0o574DHny1xMkRexKQC/CqFA7dNUNGBanNvNVzTzTI/eCp3WhFDSXVYUclZqtM6VtC4WtyIL6sfZSJZoz7zMGxVpO/WKVG1CWdPwuHAaqrxKOYOAJZKvT3ycPPngS5LRpmrSpMWQlJVZhurXSquTRjDDRsVN5X9xFbl5d49K9gIrrB4icKe8/bjyRskcvRZD2R5peXYv7gNjGHvZW2DvnpLF3i2iqPyauTrgdyjvjU28meX1GUIabWlEP94pO6fdyLVe4AsP/0/2sVbcsdID51duXmKiUul9hFDhId/PuCOZxZ aPLwXJl2 reNAc1YRIgNf+DCl0R2J3OoICMqfDQvbzTIucZCTOJeDo9YE3TrnbE9erwhrcgDfB8kL4Iq9oZBWWSOxeFJRjGgC5qSFve15wDp5pgGDjFgD6AqptpTenFY9/61zjz+KScgKP/H8OqeYyEagrORIKQgGcFraX4NJ4CvU0Xz7siGPNrTiWsxntlJ6WtHXTIH7eYKZ1YCJ1nXUCpv5sg8Jh6KiyRfwL0gk11u/qJx0Sn3hETRelT+UA9PIuxiGr9Qeyu9itbs6lchDEMCfw6vq2SnkXS7Zc1TOC7Jh2SSZ8dbAfn7JtcmGztIIZZCLCLVX0/rksA2yua9rS3EerBUs1amPrRSzLmEKzG5IzOHeqERLu5JjH/qg2J38QNCf5RZQJapE9dIYrq6blXEfBBtLk0viRLD4Y1KVfDALq5PZTbBeCnXSptltxn/PjgObRX86l4xFrtLmc8AR0EPzFZk/mHKjDes2gbG1aAdjqpELWlq6NLSIQc8YWhNB+30/gmmt2gHPn 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: On Fri, Sep 27, 2024 at 03:20:40AM +0200, Mathieu Desnoyers wrote: > On 2024-09-26 18:12, Linus Torvalds wrote: > > On Thu, 26 Sept 2024 at 08:54, Jonas Oberhauser > > wrote: > > > > > > No, the issue introduced by the compiler optimization (or by your > > > original patch) is that the CPU can speculatively load from the first > > > pointer as soon as it has completed the load of that pointer: > > > > You mean the compiler can do it. The inline asm has no impact on what > > the CPU does. The conditional isn't a barrier for the actual hardware. > > But once the compiler doesn't try to do it, the data dependency on the > > address does end up being an ordering constraint on the hardware too > > (I'm happy to say that I haven't heard from the crazies that want > > value prediction in a long time). > > > > Just use a barrier. Or make sure to use the proper ordered memory > > accesses when possible. Don't use an inline asm for the compare - we > > don't even have anything insane like that as a portable helper, and we > > shouldn't have it. > > How does the compiler barrier help in any way here ? > > I am concerned about the compiler SSA GVN (Global Value Numbering) > optimizations, and I don't think a compiler barrier solves anything. > (or I'm missing something obvious) I think you're right, a compiler barrier doesn't help here: head = READ_ONCE(p); smp_mb(); WRITE_ONCE(*slot, head); ptr = READ_ONCE(p); if (ptr != head) { ... } else { barrier(); return ptr; } compilers can replace 'ptr' with 'head' because of the equality, and even putting barrier() here cannot prevent compiler to rewrite the else branch into: else { barrier(); return head; } because that's just using a different register, unrelated to memory accesses. Jonas, am I missing something subtle? Or this is different than what you proposed? Regards, Boqun > > I was concerned about the suggestion from Jonas to use "node2" > rather than "node" after the equality check as a way to ensure > the intended register is used to return the pointer, because after > the SSA GVN optimization pass, AFAIU this won't help in any way. > I have a set of examples below that show gcc use the result of the > first load, and clang use the result of the second load (on > both x86-64 and aarch64). Likewise when a load-acquire is used as > second load, which I find odd. Hopefully mixing this optimization > from gcc with speculation still abide by the memory model. > > Only the asm goto approach ensures that gcc uses the result from > the second load. > [...]