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 E20ABC369D7 for ; Wed, 25 Sep 2024 12:17:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75A5A6B0096; Wed, 25 Sep 2024 08:17:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 709CB6B009B; Wed, 25 Sep 2024 08:17:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AA846B009C; Wed, 25 Sep 2024 08:17:20 -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 3E6AF6B009B for ; Wed, 25 Sep 2024 08:17:20 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E37CA160AA6 for ; Wed, 25 Sep 2024 12:17:19 +0000 (UTC) X-FDA: 82603160598.09.9DF89C7 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by imf17.hostedemail.com (Postfix) with ESMTP id AAA414000B for ; Wed, 25 Sep 2024 12:17:17 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iemNLGCm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727266622; a=rsa-sha256; cv=none; b=eVwActWewxsZPX3Nv/TVjg2FpKmMo3bmhReWCOhbC4WQ1hFc+gjNARwSMUehyFA04Hc6/R /nShBLlHbhk+XIhfUNNmJdyB9ZxlOVixrQQdlMEvSUsUYCVVQzGLOq1S9ciPH3dfeyTRqS lbbAp9LPnzLfQSrXLZtmx9/g+4r/1dQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iemNLGCm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727266622; 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=RfamvyNrNLAKTVHJr/a3uL3GwlQLYqAprzFxSBGIch8=; b=qaYIqhG/5nOB7s8SseN1rK7+UOigfr/HzYEx3gMxXeUv4MyffKzECqLnwoA2hyiudWHinU SOTynUcl6x8/b/6AT35c6B6LTybZ6nAJkd4q56Q3tDv+J1k0N5JHpG2mqG4UXtUnCzpUSX c7vJnBhZ57VAlCwdsB7zaDV589hu+NA= Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-7a9a3071c6bso753904785a.0 for ; Wed, 25 Sep 2024 05:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727266637; x=1727871437; 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=RfamvyNrNLAKTVHJr/a3uL3GwlQLYqAprzFxSBGIch8=; b=iemNLGCmiNMSnjVIkMmNMNHnucx+vohHmEBmQgxIBiUwgRTA+KzD6HvvLYpuFLGf1f k9z+tBVKKbrPF6rHaBMhnM1PEOqWnzkL8v9WBW26fzlg9YfG2GapxCwwBaIrDa+86h1q pXle5/KayuDrT2cMb1OjE4zAdY0q8m9yzsvo9cZNOm/e50fgHKDbBkr7r1vQoumVvUHh 97xtpCxb1T9ajdpOs6eU+hS+XMRGZzbXyIp6OUvAKkt1k8U3l3yX+dXsxF2/qIqWxW/N BxPIu0rqfr2UBQubjuH61nQ8ODjUxhBQ8rI68LffW3/8fl5GBscdjlOg8OYyJuJprjvp zanA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727266637; x=1727871437; 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=RfamvyNrNLAKTVHJr/a3uL3GwlQLYqAprzFxSBGIch8=; b=wb+aKy1ktAVYZlpYDFaV2RVu1Cl9kM2XfiI38RGw1VE0WqNskn54HQrYwTvC4FH514 NbgAg7qAiG6HnBG5imf0SVdmIW/ZGF9tLOHtmDXlgnhHhC48dbVVkH+nogAEODCpuwPv RzYCDS+t9voRG1TE6qkupsQKgbx6jQC00Ghk44r8FWFFUO8IX1kwoUSEWGBrvtN5GHoU hbcVntUdmABbwAeiLH3kU5E8MsAus+nt5VIoJ6i5jZStxTaRr6cxq03TWkhomXoRnnsG jxOyOytP2YhckXC40Q7XpwSPbxmNNY1nqZakWj+0U/4HduIsVxMDcFGhLWYUTC050/4Z +koA== X-Forwarded-Encrypted: i=1; AJvYcCWUCiFrsO4emrkHhfQHDytgCWvKIkO6q/fjzKn7M2vYYKy8O0gzBf+W4KsTu21sP3rRuYf57iKCZw==@kvack.org X-Gm-Message-State: AOJu0YyoboyCQk8LnS1vAwsD4K2VuYhtH8yzvCrIOX8tDjZEtSMIsB2y QFNTJnLW0IwLtjiDd69Uj2TD6PMF3EUUQi3ZE9M8LZhWzdzlEFK4 X-Google-Smtp-Source: AGHT+IHiPFXBYm9II8VMy+jpneK1EOwCUCltshSdJ4SGf3Pi2WXgD7UwIafZGSQkUKkmgDxrtvRjMQ== X-Received: by 2002:a05:6214:5992:b0:6c5:9afc:6046 with SMTP id 6a1803df08f44-6cb1dc21005mr44705366d6.0.1727266636532; Wed, 25 Sep 2024 05:17:16 -0700 (PDT) Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6cb0f552c15sm15658226d6.76.2024.09.25.05.17.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2024 05:17:16 -0700 (PDT) Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id 32B6D1200066; Wed, 25 Sep 2024 08:17:15 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Wed, 25 Sep 2024 08:17:15 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddthedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvden ucfhrhhomhepuehoqhhunhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrd gtohhmqeenucggtffrrghtthgvrhhnpedttddugeeuveeghffgueffteffueehkeegtdff feehhfejfffhgfefgeegteeghfenucffohhmrghinhepvghffhhitghiohhsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhu nhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedtieegqdduje ejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdr nhgrmhgvpdhnsggprhgtphhtthhopedvjedpmhhouggvpehsmhhtphhouhhtpdhrtghpth htohepmhgrthhhihgvuhdruggvshhnohihvghrshesvghffhhitghiohhsrdgtohhmpdhr tghpthhtohepjhhonhgrshdrohgsvghrhhgruhhsvghrsehhuhgrfigvihgtlhhouhgurd gtohhmpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghl rdhorhhgpdhrtghpthhtoheprhgtuhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtph htthhopehlihhnuhigqdhmmheskhhvrggtkhdrohhrghdprhgtphhtthhopehlkhhmmhes lhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopehprghulhhmtghksehkvghrnh gvlhdrohhrghdprhgtphhtthhopehfrhgvuggvrhhitgeskhgvrhhnvghlrdhorhhgpdhr tghpthhtohepnhgvvghrrghjrdhuphgrughhhigrhieskhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 25 Sep 2024 08:17:14 -0400 (EDT) Date: Wed, 25 Sep 2024 05:16:31 -0700 From: Boqun Feng To: Mathieu Desnoyers Cc: 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 , Linus Torvalds , Vlastimil Babka , maged.michael@gmail.com, Neeraj Upadhyay Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers Message-ID: References: <20240917143402.930114-1-boqun.feng@gmail.com> <20240917143402.930114-2-boqun.feng@gmail.com> <55975a55-302f-4c45-bfcc-192a8a1242e9@huaweicloud.com> <4167e6f5-4ff9-4aaa-915e-c1e692ac785a@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4167e6f5-4ff9-4aaa-915e-c1e692ac785a@efficios.com> X-Rspam-User: X-Stat-Signature: 9mzcy7uf4ytdmgd9gnn8ionte5zwju94 X-Rspamd-Queue-Id: AAA414000B X-Rspamd-Server: rspam02 X-HE-Tag: 1727266637-548475 X-HE-Meta: U2FsdGVkX19bFuqmm084cNoHyrANZeYZy/pOskTlgoHawt+NnWJOWpFpfgqLLr7/Ld88Cx8jFTlnkih1lpdFa05Ly16/8OsvfM+bbBxUO+XD3CHFSBueNJmuUWTNuHS4fK4Tt2bSIF1tnWbTdRiTnzzXhoa9/BsdT3Vdq1wjcaJlMKRZsH309lJ7KG1DALB3TGNoP4INIi76mdk+6Mpy8f6o2IU/Ab3/lVIlYDZgaJ+Rqy9SH+Y75xrW49s6yZ6pys/tutwER5trebY07/AqNM7uD6P9ksqgNwza0iECqpQVFC9doVTF/JjhOY+TH4Cghq0zbLAuJi/iORGalZ/Y/M0Vxk0Rj5LJNyqeRJ/gO352NG1PjUzJtWrYcbdhYI2c/PVak/bHmw/QTB2ml78sU5NFgsawqNi9eIF2aiHR+mg6LCnc9NtuirCWiGVPn7UB89MIx3E7erWSop1k9YIfF68Cj5mXQYMdfWThsAb/HUIQBpD9UWKI7wNdJ6Ohw97c025XJQtBN1dMf8QeIHLzJb7miGeM+zG0Pz8a9++wfovksR63wFSVpugANWNpuQmBRQtz8xElyaVZRp2UXqdb1Y6JbM/YEV/SBU2LWV4XQa3ocA0oq3aSJ8TIooH/Lwfld7uEbLWrQt+/jQSzNHQ8jZU2me9FQe3DScWuYP8p5eMWAe1ASOabdo2B1NqTJJBLtASoMfhN2qSjGU8ed+1rjrXBEz3JVZN5TmBaZ+FowY9XGfNf5C1S61/ZaXD15uHvsFifSSdupYHUj785jCDt+7TqeTD45IGUcOgQzhi2jippVp7c+5wABINkn6hTkvoXMMZPNUItXYqw+3mvCh+PcN1Pwj+dYCTxx6NhQiFggEye+hNQqUDDH3R/MOqTVnU8x3G8pQEHFmGUUtprV3mphmQ9Ef8eE7exQELF9K93+ktO+bkwE6zdEWZ6cA7vNyo/EH6w7RsQBzfgP4XiN/N cBwHK0HJ 1Om4NJlSPu0y11zRF6q5tSxUyyk9Mwdk39jq6dofLxD7laZnDyx18eVwcH7MrgeIWp8p7n7iV7Ju/qv+ZjR+tEuu5aiqcwVEN5aw8zUo2lJH5tJlOmT1TKYXeBjHf4eS5BSxBybM18KxQo73G3znJ/zyeZWGujFgzyd7Ylbt2KkbxtKXZGmLVF7EnA0Yk+F5Xqh23UjPysveqa8RCHr+z+VKURX5Zd1jdr+zhwUv3wx7cnQPYF/nHL1o/Q9Y+LBZk/vQTIJIxW4lx0iqGe7NuZs7ZU1qK9obQ8bc5ckCFQF7uUKganZop9ijBg8bMR9SlFQlGlvbbyv8znI4idn+fTcUGAsF9sMxDOA3N6dzXx9x06OeXPUfskICzGpVWoxPeFgZRNcw2INfsra5BgzvtQsD4BUKuM96fu1E0v1ntwn4lCXaEhRzmGgDA8snp07Zop+Ripzla0WyvLtDe6P2yj25KJKvQgx3Pc8q2tDJQeN6bDgrzK/TkRFvU83KGkBXgS4kVdmU2c8ZXoCCN7itXnf6KdQWtjUR40fM0 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 Wed, Sep 25, 2024 at 01:59:06PM +0200, Mathieu Desnoyers wrote: > On 2024-09-25 12:45, Boqun Feng wrote: > > On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote: > > > > > > > > > Am 9/25/2024 um 12:02 PM schrieb Boqun Feng: > > > > Hi Jonas, > > > > > > > > Of > > > > course, if we are really worried about compilers being too "smart" > > > > > > Ah, I see you know me better and better... > > > > > > > we can always do the comparison in asm code, then compilers don't know > > > > anything of the equality between 'ptr' and 'head - head_offset'. > > > Yes, but then a simple compiler barrier between the comparison and returning > > > ptr would also do the trick, right? And maybe easier on the eyes. > > > > > > > The thing about putting a compiler barrier is that it will prevent all > > compiler reorderings, and some of the reordering may contribute to > > better codegen. (I know in this case, we have a smp_mb(), but still > > compilers can move unrelated code upto the second load for optimization > > purpose). Asm comparison is cheaper in this way. But TBH, compilers > > should provide a way to compare pointer values without using the result > > for pointer equality proof, if "convert to unsigned long" doesn't work, > > some other ways should work. > > > > Based on Documentation/RCU/rcu_dereference.rst : > > - Be very careful about comparing pointers obtained from > rcu_dereference() against non-NULL values. As Linus Torvalds > explained, if the two pointers are equal, the compiler could > substitute the pointer you are comparing against for the pointer > obtained from rcu_dereference(). For example:: > > p = rcu_dereference(gp); > if (p == &default_struct) > do_default(p->a); > > Because the compiler now knows that the value of "p" is exactly > the address of the variable "default_struct", it is free to > transform this code into the following:: > > p = rcu_dereference(gp); > if (p == &default_struct) > do_default(default_struct.a); > > On ARM and Power hardware, the load from "default_struct.a" > can now be speculated, such that it might happen before the > rcu_dereference(). This could result in bugs due to misordering. > > So I am not only concerned about compiler proofs here, as it appears > that the speculation done by the CPU can also cause issues on some > architectures. > Note that the issue is caused by compiler replacing one pointer with the other, CPU speculation won't cause the issue solely, because all architectures Linux supports honor address dependencies (except for Alpha, but on Alpha, READ_ONCE() has a smp_mb() after the load). That is: if the compiler generates code as the code is written, there should be no problem. Regards, Boqun > Thanks, > > Mathieu > > > Regards, > > Boqun > > > > > > > > Have fun, > > > jonas > > > > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com >