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 79035CF6497 for ; Mon, 30 Sep 2024 11:04:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6F426B027D; Mon, 30 Sep 2024 07:04:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D519A6B027E; Mon, 30 Sep 2024 07:04:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0F3A6B027F; Mon, 30 Sep 2024 07:04:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A417E6B027D for ; Mon, 30 Sep 2024 07:04:30 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5C16C1C77B2 for ; Mon, 30 Sep 2024 11:04:30 +0000 (UTC) X-FDA: 82621121100.06.255975C Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf26.hostedemail.com (Postfix) with ESMTP id 75898140005 for ; Mon, 30 Sep 2024 11:04:28 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="C/P5vZLe"; spf=pass (imf26.hostedemail.com: domain of "SRS0=t0A0=Q4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 147.75.193.91 as permitted sender) smtp.mailfrom="SRS0=t0A0=Q4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727694230; h=from:from:sender:reply-to: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=hoTi7stkWbLeEEEjOhpWzIimjhKs43e0L1GvrNUQI4E=; b=ByWj44M0/GrwcrbPu+3DPuRdSCbqg5nRq0XGpmTiYz8ruKqhaVBjvyAT4AaLJwr/FUCXKF wI0mUlGxBLUq8Ykojqp9By5IqQJLU9obPWBc69R0IieklySCo2FI2GLBdlPAhFRDf0Tcgu 9BmXlMOqD/mvFMtpdoS421KKezoD8x8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="C/P5vZLe"; spf=pass (imf26.hostedemail.com: domain of "SRS0=t0A0=Q4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 147.75.193.91 as permitted sender) smtp.mailfrom="SRS0=t0A0=Q4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727694230; a=rsa-sha256; cv=none; b=DT4GSa5yM/xmsZp19osB4w9ImPXn+80pV8T4S1Lr1ZoZV+6RoF32YalVlnc09c2+6i3N6i VFSHXej5o1bDvTl530+q8zg61/ssMPcfT4JSzGmkFXyYcO9F0BpJzek2EJgxvI4c6olNfv +rUY5BZiYlzT1JpkYEgKTDqAz194m5E= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 5A5F4A418BA; Mon, 30 Sep 2024 11:04:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45BF1C4CECD; Mon, 30 Sep 2024 11:04:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1727694267; bh=NQiIbZLHWN50/ws+KIDFjx4xxlpqFvb6ih5bgRVnqkI=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=C/P5vZLe/MApdutuJdD7IdXpboJkOnr82ejl4aWFIY2nN0iymjeJrp83d8Pk81wHa Dm1PX4Cy5emOCjgmBZNSf9hGHYYQicAsTDZxz1+5OIgb0BSOq1yuQTKb5/gw+NxVZw yy/Gw1HP3ogtenV6G79kqC+8WDt4CUqWJjvgvvgd+WWdRSYvEWz9neaz/3tN9eMBvR 62WHvSaHtIwteuXCcVPMN+aEvzPpHLxhMFR7ZM1hIbet4Clpahf8BeiWGXfJ8xurFR 7whUxrFmhedCkwdff8RmITyp+PsrEDmHZ+UsaS9Hj9bLDi3x3YyFDmMl5bnj86wA+5 j/RllRuBUom/Q== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id E3B78CE09D1; Mon, 30 Sep 2024 04:04:26 -0700 (PDT) Date: Mon, 30 Sep 2024 04:04:26 -0700 From: "Paul E. McKenney" To: Jonas Oberhauser Cc: Alan Stern , Mathieu Desnoyers , Linus Torvalds , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sebastian Andrzej Siewior , Will Deacon , Peter Zijlstra , Boqun Feng , John Stultz , Neeraj Upadhyay , Frederic Weisbecker , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , Mark Rutland , Thomas Gleixner , Vlastimil Babka , maged.michael@gmail.com, Mateusz Guzik , Gary Guo , rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev Subject: Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency Message-ID: <973ae617-96a8-456a-a805-af3d61270125@paulmck-laptop> Reply-To: paulmck@kernel.org 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> <25344f33-b8dc-43fb-a394-529eff03d979@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: shoqwjj6ne7nywzhcxqc17p7bir3bu8b X-Rspamd-Queue-Id: 75898140005 X-Rspamd-Server: rspam11 X-HE-Tag: 1727694268-703332 X-HE-Meta: U2FsdGVkX19EzSVwbjZUflDngfuYIAot/CTqJ2j3ZZspXDXKXnV98PrpW9chM/azvVIwJD1cgLv46JcihoSBFxJ35cvXAdeSK9wla2C1DO1oF7ULY+frLr4K3qB1AbkrJeNN2OJ5IiJFtusztFMQymoZgAP9b5B5OfXRnMCHDCH18phnml0oCTumbExBBu6oQan0jriXlAsrecB3joHHLRHBy1d8r8oSdbM8JFKSbE7rDq1tNjf8lbKw1HxiY9i2uxVPsRj/8WTa6L6HYt4y+s+97w13q0YA07TK6L5R7xNxbQ7CzmbvRwdjg+RHeV8PIsooeQzAlfAavXSUgvjvEIgccpx36AJxxzlLJPdTPv76c7QYu3e0Lz4AIezOeLjoXP4AuRkIhhMuZkxgKffy2bNFIP5+2fYXm2hI+wJr8aCGOQdL9dL85QAPYU7cgbJkbZxIHaF+IE/8H3Uh9esZq4mlf/I/Gqd3VwNUfhDrrIu48gISiJkHOoj68AjrN99sW9Wf9J+TYjmJ/TjgE7eUm0Flb1Y7T9Y1AxTtUIZG0r70H5ZFiW2lFbmmt2WyQukM9ftQsQxTvlutCYq0QYjYvSuAvp7Z7LJI8nHZv5zV+ZHojkNIIkIgToJr25o2E9apLDPxg2rlNsJo1fqmdPbpGmWC+t2NmAf5FqvDCqIpipg4kZXbjRA295S+ooDVGxm/W+JynIdZrNcpunPfuS844oAVun8uvwtr6gB3Z6Xgyk5AR8hoY97BtSdbZAPhDlrXDg4CM2C/uJaVOSzQlRFBqGWTYKu2+VLFv54g1ppoLOeTjv17GC6USzbAYdgO3IpyUXt2wmmZep85It83uEpwLvWOqovDwXylii/0D+NL/NHwhYmEOUjzBPF4+fOwsAm+OvolmxAymhU4vwFzWh5nbXx+e1NPQYZdQEPUkbz+MiAim3bFbYA7uEjTW/+3O0eQbVU18NGb6EdfgTxH/YP yNqnyd/d DM8DrkOu0odU0pKkZ0TWhz/VUBvUB5jiRJNO4yY54q37opJDbqiZiOtx4VdLK/1t+6OvT0Ai0DjxJ/E0rNoU525bjEWe5jKPzOfIAIr1SvhGoqMiqV84me2v3y4ycgwZvwBHELasEthK6Q6j+daH+Ucun1gGI1F4BZigsZODVy/g6ZOZqtsrmelsojxlU+jbuNq6J2Qhp8kdQbQvbc+DGNOAjSNi3QNAeHKCvq4mWz8n1Mda75Ig043aWfnyme2J7685QuYdpfJ6LERBrDsq8LopHgma8OXAy6k1dUEI6R42hUvOSpiW7MuFvZWoODEpLpjhXO30dXCEDWuM9z/20sKnEvm3+ChuYyOx4BtLIh/JbcD/XVyt9+2ZUR7TXmgpqM62Z3ByJSeKIV5GGKWVWdegjO0cnHwbxOjDL04YP+XWFoQguBaWPM/KcVc+7OU/2dIG4/Um2vIA6sAlG2vKFCErScunjcuUc+bna2J17ZcDkMTTKoSFv/dqqkXrTkEAn0x4ZJDJMLkzT8LPt9hkSj4/RkbINr6g1WIiBMrHB23OlqwMtb4Pn6f72xJYnQGA1KIIwat3N4V8ubXIMDXTKd25jUp+7Y6v5pJFFiKIuM0EY06t+gSkii9Vkmf4MdAXFqejwWlJ5sFK/UQknKLQml61CLcCa4eCjna85l9kWw7H3F/gWto2vmNOd121cMLBI5N7GA3d04pKQfvz7YH8DSdQeHg== 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 Mon, Sep 30, 2024 at 11:42:11AM +0200, Jonas Oberhauser wrote: > > > Am 9/28/2024 um 11:15 PM schrieb Alan Stern: > > On Sat, Sep 28, 2024 at 11:55:22AM -0400, Mathieu Desnoyers wrote: > > > On 2024-09-28 17:49, Alan Stern wrote: > > > > Isn't it true that on strongly ordered CPUs, a compiler barrier is > > > > sufficient to prevent the rcu_dereference() problem? So the whole idea > > > > behind ptr_eq() is that it prevents the problem on all CPUs. > > > > > > Correct. But given that we have ptr_eq(), it's good to show how it > > > equally prevents the compiler from reordering address-dependent loads > > > (comparison with constant) *and* prevents the compiler from using > > > one pointer rather than the other (comparison between two non-constant > > > pointers) which affects speculation on weakly-ordered CPUs. > > > > I don't see how these two things differ from each other. In the > > comparison-with-a-constant case, how is the compiler reordering > > anything? Isn't it just using the constant address rather than the > > loaded pointer and thereby breaking the address dependency? > > I also currently don't see any major difference between the constant and > register case. The point is that the address is known before loading into b, > and hence the compiler + hardware can speculatively load *b before loading > into b. > > The only difference is how far before loading into b the address is known. In theory, true. In practice, in the register case, you need a little more bad luck for the compiler to be able to exploit your mistake. Still, it is indeed far better to attain a state of bliss by keeping the compiler ignorant. Thanx, Paul