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 0E4DDCDE024 for ; Thu, 26 Sep 2024 16:41:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 95D8E6B009B; Thu, 26 Sep 2024 12:41:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90BA36B009D; Thu, 26 Sep 2024 12:41:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 785936B00A0; Thu, 26 Sep 2024 12:41:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5A4AE6B009B for ; Thu, 26 Sep 2024 12:41:12 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E6171121A2F for ; Thu, 26 Sep 2024 16:41:11 +0000 (UTC) X-FDA: 82607454342.13.F99352F Received: from frasgout12.his.huawei.com (frasgout12.his.huawei.com [14.137.139.154]) by imf06.hostedemail.com (Postfix) with ESMTP id DCFFD18000E for ; Thu, 26 Sep 2024 16:41:06 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.154 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727368749; 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=R2+XjQm9JGmCRsO/0YsPNX3Fiss5kMyVxlnoRfdH7zI=; b=noBA9EFvz1UuCh0mqy4tqcUdw5s3KE57lOGaHCWlDWhITSKqWM24LW5T61GNyKuQGabZR0 fzrnaTFKsjAzLBEq8bLEZ6pUdxO5iglh6HRKZQLgmmLPfKn/M+8TOHok9j8/Hwsd92XArz jCnPu3H3scKD7QyWUhJSsys2MyIG38c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727368749; a=rsa-sha256; cv=none; b=1hdBzzDtnSUpKZ79uerMXwN/WoOAlGC1WoSCwuiBlUVTlaQk6JaC1MymVMZ+bfvj2tEa8L 62nhvSGmpIkON9QhveYwTqXY7J86mu0FiZ85Oxvu8Iqm5NrVD9Zhd9u2A6oyHDcbZhTBdu Nhj2bpbFMKPLPinM0FeT1g9O20x1Wh8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.154 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com Received: from mail.maildlp.com (unknown [172.18.186.51]) by frasgout12.his.huawei.com (SkyGuard) with ESMTP id 4XDzGK0wlXz9v7JM for ; Fri, 27 Sep 2024 00:15:21 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id 9F359140419 for ; Fri, 27 Sep 2024 00:40:49 +0800 (CST) Received: from [10.45.145.4] (unknown [10.45.145.4]) by APP2 (Coremail) with SMTP id GxC2BwAniMiBjvVmk3azAQ--.33772S2; Thu, 26 Sep 2024 17:40:49 +0100 (CET) Message-ID: <54487a36-f74c-46c3-aed7-fc86eaaa9ca2@huaweicloud.com> Date: Thu, 26 Sep 2024 18:40:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers To: Linus Torvalds Cc: Mathieu Desnoyers , Boqun Feng , 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 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> <48992c9f-6c61-4716-977c-66e946adb399@efficios.com> <2b2aea37-06fe-40cb-8458-9408406ebda6@efficios.com> <55633835-242c-4d7f-875b-24b16f17939c@huaweicloud.com> From: Jonas Oberhauser In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:GxC2BwAniMiBjvVmk3azAQ--.33772S2 X-Coremail-Antispam: 1UD129KBjvJXoW7KFy7KF4kWF4UAF43KFy5CFg_yoW8tr15pr W5KF48KF4kXayYkwn7tw47ury5AaykJFW7uF95WrykArn8Wr1Skr1SkFy7Zas5Cws3Xry2 yrWSvry7Xa4ayaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxV AFwI0_Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40E x7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7CjxVAaw2AF wI0_GFv_Wryl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a6rW5 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUIF 4iUUUUU X-CM-SenderInfo: 5mrqt2oorev25kdx2v3u6k3tpzhluzxrxghudrp/ X-Rspamd-Queue-Id: DCFFD18000E X-Stat-Signature: ck4wh7uzy4gumm3q1pf9b9nbf3xdjdjg X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727368866-99343 X-HE-Meta: U2FsdGVkX19zpdJKaro1305GV0KvzMZV4sywM5lJx7fhaTIBBJrlYMa5BCgDt22TDIAOdkkbDy0Ey7lNIFlY2jnus7VrZ7rBb9KRxvOf1iRVr+tNXdiqfYQyb01Vppn07qMcwmfXbscB3oN0bM+2iotMrt8bo/QLTBJbFl8K4bOe+LESQWD8l7N3i2Pv4JtndJcKF/Xu2Iq6aW8QX25Qo2GRxr7CDiBYBm1EY9Yk3Olq6Aipe4tBjqhQ4C2z0ASI4SybVuNBSoM0J1KvLVwjuDrYfxDZPyVqnoiscAw17LX66kGHLvPjn8elGg1ihST0TY7AH/jdSea9QX4hJlWZ8Qzz2TWosdYEjOYPi8Cfx3cAlmlDddAyf76tRVAyltD1BWA0/Cphk4fMJLr6zdOcsd1n31szawBIceWlngCMDNGyYAWid+0OOTPzv+V7LmZGNLsg9M3UwAJhlMJ5wvzZYnjS6n78uLzoj7ZxHs9UAIBir5MP8PKF3yErd+OMCTFcpBEvnZ/6YMqv8p+WMIkVIpBc2nSZubWJY839O427DbnNMJVR/3dUbNLt4xqDpnuJ25xxZxXSrwfPCRP5aNLg+UJi5XTdQILhKqQlOvSWjFQn23zbEqwy6CrOl73f7fLTfMSqh7jNjxhI06XJF+ubBnxJJWiMkZZpu/Gg7TSCis10GBqmCNNW2Nrxb/nlED6c8h13auS7e6atHFUmdWYH5u1ZQLEZBfbn6+xxcRm8QeMQxEcQbtePIOvPgV3shvx6lZb8MKQQyy85s6SO5WcO5PlOneNi5gUxDnQ/fqPadKfb22B6bGIz/5D3b3twwt4sJr0oPc6iWDZyh7q3bdCgTfPLGDYwxZ4R2Gde02+dokIkZUL2IZR/TryIh5CeLgdLVCRMJXZqNTqMDUIqzGYAPUEdmHHTD+8SABnxm9ONaM7mrH24pn42oKVGSiipJ39BIctdbFp0rxWttrMwdzq pQbHA65s pzjftJcIzygQUeedkWl95JswcWQ7sWXVHXs41uJBr4kyMIMbyxlGyWPgHMPSv88thk7NJjjUMub4O/7NiY17P7WyVo3EW1SG/MwvxsArgxbkMT8WS0lsRTtzVm4JaPg5ecncL4y7rfAXJGEaUy/A7XvpUxDD0W+XDDbFhvwtjvJBpOOlDUFEhcQ37Da65E/QHXaP9aBXO87ESbxqwRZxFOiTy/DYasTMm8JSo4r4gzumBo6Q9UWiJXMVCgwQNQXC5t8Jd 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/26/2024 um 6:12 PM schrieb Linus Torvalds: > 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. What I mean is that if we only use rcu_dereference for the second load (and not either some form of compiler barrier or an acquire load), then the compiler can transform the second program from my previous e-mail (which if mapped 1:1 to hardware would be correct because hardware ensures the ordering based on the address dependency) into the first one (which is incorrect). In particular, the compiler can change if (node == node2) t = *node2; into if (node == node2) t = *node; and then the CPU can speculatively read *node before knowing the value of node2. The compiler can also speculatively read *node in this case, but that is not what I meant. The code in Mathieu's original patch is already like the latter one and is broken even if the compiler does not do any optimizations. > 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 Exactly. The inline asm would prevent the compiler from doing the transformation though, which would mean that the address dependency appears in the final compiler output. > 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. I'm glad you say that :)) I would also just use a barrier before returing the pointer. Boqun seems to be unhappy with a barrier though, because it would theoretically also forbid unrelated optimizations. But I have not seen any evidence that there are any unrelated optimizations going on in the first place that would be forbidden by this. Have fun, jonas