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 32706CF6497 for ; Mon, 30 Sep 2024 09:42:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FAAA80023; Mon, 30 Sep 2024 05:42:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AA3680017; Mon, 30 Sep 2024 05:42:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84DFC80023; Mon, 30 Sep 2024 05:42: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 5E94580017 for ; Mon, 30 Sep 2024 05:42:44 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0DAB5A0259 for ; Mon, 30 Sep 2024 09:42:44 +0000 (UTC) X-FDA: 82620915048.28.6E1E46B Received: from frasgout13.his.huawei.com (frasgout13.his.huawei.com [14.137.139.46]) by imf06.hostedemail.com (Postfix) with ESMTP id 87384180004 for ; Mon, 30 Sep 2024 09:42:41 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.46 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727689236; 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; bh=GvqERs9wSUpUh2DPaX3wOqOBDzfl7gsY1uUxiBD6iTw=; b=lBOssq6oCwdxDYeqJbFYeYFJD1f319YhhTi15vEMNAO5YbiczV9MZSl8FO8GM8b12qzNmc lZiv4WCB1LCN4ba1ky+Xy6DFq7fVu3sTwybO+BbWNIUSEcJ/QfHnnl1GaAiw5VEAk6mvs9 LItpAREwqDWkQLV3iiyVpTCyLTXOugA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727689236; a=rsa-sha256; cv=none; b=RtNPTDXKMR8fMWcYcEpiaRkEgEaUPLBOdDMrurJo41j0/erCQpJMY7Q88L/3/687zghBvy Hx+vdqzAAEMKgsrX+UpwWNU5m0PMTznQ8xy40r2jkFgMN4n2qTUzPgeimsSptElJgZQTYX UoMIwTn16obbgcVfv8zJP5Jag2W/YL0= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.46 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com; dmarc=none Received: from mail.maildlp.com (unknown [172.18.186.29]) by frasgout13.his.huawei.com (SkyGuard) with ESMTP id 4XHFwQ2mhGz9v7J5 for ; Mon, 30 Sep 2024 17:22:46 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id 6DAAB14040D for ; Mon, 30 Sep 2024 17:42:28 +0800 (CST) Received: from [10.81.211.60] (unknown [10.81.211.60]) by APP2 (Coremail) with SMTP id GxC2BwAn18d1cvpmZwzxAQ--.6356S2; Mon, 30 Sep 2024 10:42:27 +0100 (CET) Message-ID: Date: Mon, 30 Sep 2024 11:42:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency To: Alan Stern , Mathieu Desnoyers Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sebastian Andrzej Siewior , "Paul E. McKenney" , 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 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> From: Jonas Oberhauser In-Reply-To: <25344f33-b8dc-43fb-a394-529eff03d979@rowland.harvard.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:GxC2BwAn18d1cvpmZwzxAQ--.6356S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ur1DKr13GFyxZrykXw43ZFb_yoW8Jw47pr ZrKF4qkF4vyFWYvFW7Zw48Ca4jyw1ktFyFkrykKr47uryFqFyfuF42yr15ZFy5Ar1xX34Y yrWFq3W2gasxJaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvFb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I 0E14v26r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8C rVC2j2WlYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4 IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACI402YVCY1x02628vn2kIc2xKxwCY1x0262kK e7AKxVW8ZVWrXwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c 02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_GFv_ WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AK xVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvj xU4R6zUUUUU X-CM-SenderInfo: 5mrqt2oorev25kdx2v3u6k3tpzhluzxrxghudrp/ X-Stat-Signature: qwuj54hfiwsh8aqme616ao5tu6cza955 X-Rspamd-Queue-Id: 87384180004 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727689361-377494 X-HE-Meta: U2FsdGVkX1+dKb9qTzG9ixjlpCU84HR9uigZeVtGbiwo21FJXLwWmRL4BZr5+lmlN5KLbTVuVDh7ooEoh43iN4+mbH0b7ag5jt66NLyscKZarwesNzwwkpeWWilg6SaiGQJSluLFKbyfzeuAmjBUe/RuFA9RfhJSvy0nGGSGs27ouDSB3PcSk2catysBCrQrjVPfgewKIAi1dKYTlTljCDm4ZOOniAoi8+6N7YYKqpAAN8MM2dCZHBgCvCGenptgCeqGZTHc8qTL3RCxak18q56qbJoTxalfmc8Cbr6M9gi3va+c0yyyL4l0xj7w3GAE87nUlkrVdAtWIdxZsqLyRSmmDt3toAcDG/idnvOU0iXzBRkKTvc6ckBRfJvc70Bxn9JC8DCWwLLjehFb4dygRKWrZJtUKS+Dkhko3O9OrDPfEy6jXRnTAQD+fECktGHpIoEwa+cVp85OBHUTuYXAW2M+GygIAOqo44tsdhYd/vknwmaFUFm6DyaoWOeOdVfQHKPJpePnlSQddVJwBUbn3x3tKvJgCX77eTsrImUyMojtqn+h9edvVPb2pwrR+qQnKCjTrYDgHryPlGHKDBV7HmVgGjCLNYBZ3YJYfBa5D3fKSKRwZyuC85g7nqc+R85juZGP6AdOgesNJQ3A0rwWmjOS7jwvmOiNqHBjrZkxfXi912X4oaeJYjwGRru7tLJZ7uGD34ADqr4altosBQPYXSPUrdzzFiRBxPf/dA9TAI5AV2LhzWYr2/3/gmiczOGqUkOx6o8DF6O+K2cUYwKocX993f6360oeIRA3YHH6nE79vR3+ub7wLmNQ2XMnQpdEpYj2Px8pqHqQe1JoEKYsiRPAJFRXWC03tHxg1ZZdm3p/4kWGe2SQt3YO7FdCjJodEoupf2IyWdOdQrB1ZX4SICDNmiXVLw5kCzMw1tNUFCgejcIxwl27V2AqM2TvTREpQZFXGOrVUXgnKTK8gBW 0VzpVqRq 630H5Q0I7S1RjdBXVl3BVYG0lu5E/IBAM4ZI7Hw9I4AO0OnYVdDvExkqKY7mn1R6E/8RYjg/S9mznG5wgDbIlHZnS02JDNV0MmEnGu9sn8+3WSeFSKBIVhKPSKwuckfguSHh4TI2/RcKFKpp4BHVsavCaNx4wslhTItWl2QK9HSPnDMiLI4cZhMlr2iC09cuW+zVJi6oCieq8xQLmbpofbrGIEG2YlGfiH6GSsV5MqIoblXGfQ7zMPAc8VQeyBC8yf51PPKruQTsnezkpSP00ArJKKQ== 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: 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. Best wishes, jonas