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 D07F8CE8375 for ; Mon, 30 Sep 2024 17:05:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6505828000D; Mon, 30 Sep 2024 13:05:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60390280003; Mon, 30 Sep 2024 13:05:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C7A328000D; Mon, 30 Sep 2024 13:05:41 -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 2C303280003 for ; Mon, 30 Sep 2024 13:05:41 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3895716087E for ; Mon, 30 Sep 2024 17:05:40 +0000 (UTC) X-FDA: 82622031240.05.1767580 Received: from frasgout11.his.huawei.com (frasgout11.his.huawei.com [14.137.139.23]) by imf08.hostedemail.com (Postfix) with ESMTP id 75A7D16002E for ; Mon, 30 Sep 2024 17:05:34 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.23 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=1727715811; 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=k2JFzYtXoXeqKsnfGoZRcku29RdNeLIfaEG12E/P6A8=; b=yVw0Hv2tjuBoA5sNcjZeyx3/kqeuFHYTNUSFcIcMo1NAwTcbOK74CFuXe+1QfF/oIAOlIo W1i2B6FAePAOel5XN3wTQbq/Kt32ClnUzOjrtrYtEwOTdpFxkxZl58AB+mZvGQBpmDvqOo SV1F5AfTNZe3iuhLybfDM3ir3xFYjrI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727715811; a=rsa-sha256; cv=none; b=NDEABThmd76GMX53hLFOrHWl9gcwz0CxFbODNex1eYBNMEsFE96r5YMNK+vg+yd4a+gyUs Mj6G0sUUvOl4RL2ID6XoaPSnaPcrJP/BR/Kr5Il3T+MCWkqSpYgYn9OhTnn24id8Gbi7FX I0K4m8w/PIZoudNJT7KqhrVl1Qc2OiM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.23 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com; dmarc=none Received: from mail.maildlp.com (unknown [172.18.186.51]) by frasgout11.his.huawei.com (SkyGuard) with ESMTP id 4XHRlM6K6Rz9v7Hq for ; Tue, 1 Oct 2024 00:45:35 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.47]) by mail.maildlp.com (Postfix) with ESMTP id 0950D140A26 for ; Tue, 1 Oct 2024 01:05:27 +0800 (CST) Received: from [10.81.209.28] (unknown [10.81.209.28]) by APP1 (Coremail) with SMTP id LxC2BwAnuC9G2vpmEMjxAQ--.62409S2; Mon, 30 Sep 2024 18:05:26 +0100 (CET) Message-ID: <5d7d8a59-57f5-4125-95bb-fda9c193b9cf@huaweicloud.com> Date: Mon, 30 Sep 2024 19:05:06 +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 Cc: Mathieu Desnoyers , 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> <9539c551-5c91-42db-8ac1-cff1d6d7c293@huaweicloud.com> <2cdda043-1ad9-40cf-a157-0c16a0ffb046@rowland.harvard.edu> From: Jonas Oberhauser In-Reply-To: <2cdda043-1ad9-40cf-a157-0c16a0ffb046@rowland.harvard.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:LxC2BwAnuC9G2vpmEMjxAQ--.62409S2 X-Coremail-Antispam: 1UD129KBjvJXoW7uF4xJr1fCF4kCF1fKr17Jrb_yoW8Zryfpr Z8ta15KF4kGw13Crs0yw15ZFWa9an3KFy5Wrn7XrW0kan09FyfKF47KFy5uF9xZ34fJrWj y3yUurWfuFy3JaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxV AFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWr XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVjvjDU0xZFpf9x07 jxCztUUUUU= X-CM-SenderInfo: 5mrqt2oorev25kdx2v3u6k3tpzhluzxrxghudrp/ X-Stat-Signature: sumeb6n6qboutrmexc8thst8pi4n7jwp X-Rspamd-Queue-Id: 75A7D16002E X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727715934-996411 X-HE-Meta: U2FsdGVkX1+CX78qg8+KAc8P1KbDw48PWYOO2/uhKbdYXDOl4/ompRIQWX+6hlap3oZa+QcspWk4cTsWeqvRLGrMkJdFyy/HHONmDJGVoRgWvkbAhO4QxmtsSirvoXs2Svy+3XOp6bqXd9cBLX4TFhnUq7VtEnauvZ5A82RY7oeucQoYynS8CbcA20wbB1SQSNhKhZWLLrh2T7SjMKitU/b+tcSGcXUZLppycFTtZPBlz7q86hm2QQBvttYRj6TBliR0YNUbL90JgIyq+l9O8jXUeDPSoYCB+aHJnTKU1R94q6r0qrX+J87ACRGE62JcAD3gR4aMZcPwsOTW8ajIEYatBOm1A4NtZkZ4asbsK6oia8s7qLEOk9uC/lIg5Ros6oFox60lJgoENlEehZ29ue82kmLCowRYgBRhydYVFO5lSMTzWRjwSW+ntJPM/vXCBAsEjFEzZ7UV8Zp9BPgTTvT46l8vBZw5ISLQsHhcEk6vFFq7nzrleE4n3clRcoNs8IoG8zyabmycNsbDgrX6Ip1YS8oDpOFmenjxuZkCJ77QrDLznUa/G3nfZmi3P41ieX3vgqssY9vkomEKK0PeNbp6Mw/4OuUkV9KyxFC+kiis8+4kfqb0mWJAe5PfGATVEm971qxJ3cDDEXYMYvVC1URLSL08ghtQkT187wuHbAOeyXRvBDJrzecZ0/3iTkkhfhAo7t9LiE2udYETTr+bc3jn1928jmSBeqMRk/cj4awF5EX0uCQ3MJ/g8UcBIrmzTqZa1a86u/hefHtxgXXMkHKnOkCL/vSi50iL1pdhYQ10b2+yDUboMk40/be31vuXdBB+SKhFzxU7Shxjq+MPEq7BQH9Ps3s1qTCMxbD0nAtATNOfyMiONP8S6d/mJh8JWCUdnCMOqOFOiB1E385VaoaXEiAOHmJv+jNWBDRLCXJqlJBwcmD/yx8GDmYeXfkKtGQNWfQexYT+DTrNLGw nFRiELO7 bsOXYT/JQBaSt5LEzeb9D6YnX/A/J8nI7fwMSfkZYrLE2yQkrHMG1nBV4bF+f7b/YwwYSrg43Esdm0kQQw692P9j7q43WGFpGxfTKO9mknfnRW2v9wCqm81ITwdw1/D9AAFErtouSvxVhABUdqimcPKj/g+Jyihql5tolPCyW2LiUznjtzm6ZTHrtmQATRsFSRFo7zTSqfyHUqn+BIqR5sExN8iBefytrHXoJeBpwpKC4YGfL0MklwgfpfKN/Todd6DpuWtoBw68SxJHLTLfrLpBoOA== 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/30/2024 um 6:43 PM schrieb Alan Stern: > On Mon, Sep 30, 2024 at 01:26:53PM +0200, Jonas Oberhauser wrote: >> >> >> Am 9/28/2024 um 4:49 PM schrieb Alan Stern: >>> On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote: >>>> Compiler CSE and SSA GVN optimizations can cause the address dependency >>>> of addresses returned by rcu_dereference to be lost when comparing those >>>> pointers with either constants or previously loaded pointers. >>>> >>>> Introduce ptr_eq() to compare two addresses while preserving the address >>>> dependencies for later use of the address. It should be used when >>>> comparing an address returned by rcu_dereference(). >>>> >>>> This is needed to prevent the compiler CSE and SSA GVN optimizations >>>> from replacing the registers holding @a or @b based on their >>> >>> "Replacing" isn't the right word. What the compiler does is use one >>> rather than the other. Furthermore, the compiler can play these games >>> even with values that aren't in registers. >>> >>> You should just say: "... from using @a (or @b) in places where the >>> source refers to @b (or @a) (based on the fact that after the >>> comparison, the two are known to be equal), which does not ..." >> >> I should also point out that it is not enough to prevent the compiler from >> using @a instead of @b. >> >> It must also be prevented from assigning @b=@a, which it is often allowed to >> do after finding @a==@b. > > Wouldn't that be a bug? That's why I said that it is often allowed to do it. In your case it wouldn't, but it is often possible when a and b are non-atomic & non-volatile (and haven't escaped, and I believe sometimes even then). It happens for example here with GCC 14.1.0 -O3: int fct_hide(void) { int *a, *b; do { a = READ_ONCE(p); asm volatile ("" : : : "memory"); b = READ_ONCE(p); } while (a != b); OPTIMIZER_HIDE_VAR(b); return *b; } ldr r1, [r2] ldr r3, [r2] cmp r1, r3 bne .L6 mov r3, r1 // nay... ldr r0, [r3] // yay! bx lr Have fun, jonas