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 5CBD4CDE01B for ; Thu, 26 Sep 2024 15:54:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB5806B0096; Thu, 26 Sep 2024 11:54:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3EC06B0098; Thu, 26 Sep 2024 11:54:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB8AC6B0099; Thu, 26 Sep 2024 11:54:16 -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 889F06B0096 for ; Thu, 26 Sep 2024 11:54:16 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3B9991417B3 for ; Thu, 26 Sep 2024 15:54:16 +0000 (UTC) X-FDA: 82607336112.21.C209474 Received: from frasgout13.his.huawei.com (frasgout13.his.huawei.com [14.137.139.46]) by imf27.hostedemail.com (Postfix) with ESMTP id 1787A40021 for ; Thu, 26 Sep 2024 15:54:11 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.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=1727365932; 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=nJTyYqICxpTmTMcbhnAfNIFSwgR45ux1e7IDPasyKpE=; b=j9wWjhkoELOCY0xJlnYOGpqp9GoqTkzBR1nuToG8taBui/PJwPGx5M7TCCq2FJUMtCOcxy /pJ4YprxAZSmeocx2Dh8bRYDQg6ObTnSmZxUplSAY1eUjQuDs2b97TCrAXTzXjr6FyNkRb 6fHpa5jaJ9vZCAh7vAsZoII32ZG76KI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727365932; a=rsa-sha256; cv=none; b=tR1HS7jXEWvnD6S9h3JyoDbU90MN2XHcQRCT9LV2Drknc4KSDpTvMn0E9e0KMlEqIPc8wJ GuSvn9fel6UYhU9/turzmgzhCD2KBxw/MARRZ9/Qs+zTyTs6qOusV+MH906AdhrwPdI0GH iI41giqB8CsrYROdhn5Rtl0QWLhVjaw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.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 4XDyM204swz9v7N8 for ; Thu, 26 Sep 2024 23:34:22 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id 8015A140155 for ; Thu, 26 Sep 2024 23:54:02 +0800 (CST) Received: from [10.45.145.4] (unknown [10.45.145.4]) by APP2 (Coremail) with SMTP id GxC2BwAniMiLg_VmEOyyAQ--.33525S2; Thu, 26 Sep 2024 16:54:02 +0100 (CET) Message-ID: <55633835-242c-4d7f-875b-24b16f17939c@huaweicloud.com> Date: Thu, 26 Sep 2024 17:53:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers To: Mathieu Desnoyers , Boqun Feng Cc: 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 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> From: Jonas Oberhauser In-Reply-To: <2b2aea37-06fe-40cb-8458-9408406ebda6@efficios.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:GxC2BwAniMiLg_VmEOyyAQ--.33525S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Ar4xWFy3Jw17Kw4kAr48Xrb_yoW8AFy8pr 4ftFWxXFWkua1rKwn7ta1UuFW5Jr4xJay5uF95JF18Ars5XF10qF12qryYga4fCr4kX34U tFW5Xry3ZasxJaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 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-Stat-Signature: 8chert59qzjnw1n6hityj3qp6hs517rr X-Rspamd-Queue-Id: 1787A40021 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727366051-528861 X-HE-Meta: U2FsdGVkX1/fq3GoqFY8pDZtiQmZOnuFI1+5tYKLAcPoutB9rZqIavAmpie1uoViX1gacHuZ214J0yT7s51kujvncWdEihr8LEvOv2vqfu2Ys0vVyaE1sZOP3b3RhjMAlsZDPdEFNq69pXrFswxSnimh2V7S1B9CuIftFeckBCG3ncSlPmrGNgTrPhVJq+2qGb7j7eBd7PW2UdooFuzqdKpuVD+ET6km7rUFqnKVVg+BCp44n0JimgOqzYT6YX0F2S6VXFHrHx4xCDb0jkMd3tUzKwve1bd26tSGXSAx5u5PQsz7u346A89QH1pJ33bQTcOKfh1Y3wHMfrnyXgz4EqRRa1/Ovo8/JE5zduLj84uhEiD6eWhTiPyeKhdrXLbzJtZDDYcY+dDS2rTgsFE5aiCeSm3DMS+nNi7clwR/CY9aV8SOjyghjL/xSzODA+pNFvzBFfLNEBIltqfa3zS1poejhO/RuSKL+FN2OgSsSmdrrd8GBLclV9D4zmLG0aASJNXfb09YU94oD3BzffR2vcKL7e9tXLhg1CLTclaeOds3I6M299KlEwAZsyWvwWL/guPIA3xIejSazvz/IxJsiJRzvrgyQEJm/Xi07sLi80nh9nRVlllaroCeIe0AdvnweXbKDsQKwOVzP+FNuxo5o+Y3e7XsTIPR7cuF8m0rztPFr1pxvLFGxjGWCOWVA7l8wv03CFnFOwkrFLkdkJ51u7oXutiCPWts0FO0EFZBH/VUTkRmYKY6BvzJ0n4zWpL4ygmcDBYTm6tT+frZcQCLNYuLhAKuFk/gPuZt7CVrFS0P/PhRZuPC+NmRt3e0QmqvbtXQGFcHJMWTnVTN8j2jnhrVzQSjvF5wVXpcFsS4/sBfae+RWakOvYl+bc5XlJBB7pa+nNftANqJKTOKm5ysDbCxHznrBDnVQ8I/+rG6V1ospGGwFM4/Q8pEblWYIwQcXaWzXxoxjAFNdGZ78fU CUwkVNBM dZnoDIPyCiwd2e8QShY/Wk6rE71JYXRHXLwuFWNINUh/n1n60hgBBcgnR3qx/SWqfRPGAJPRuHXlOL0+s+pN5LNwG5cjk0AMjKMLZdZPLDzTs8utjUxR7DhXGJ20vQ6i4+090aBvWRwJ4U3cyBdbWIDf7K7fc9gXOHqy8Wd04Wz4S/qEkje0L1YfoYzHQ6kV3k9QKHfCEyoeDOMjjGfsTOV50qL6WdMFGFYHTZ+lSZ/+EtLwRAhOdNp0V2/6xHLmZtL22 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 8:16 AM schrieb Mathieu Desnoyers: > On 2024-09-25 15:20, Mathieu Desnoyers wrote: > [...] >> static inline >> bool same_ptr(void *a, void *b) >> { >>      asm goto ( >>          "cmpq %[a], %[b]\n\t" >>          "jne %l[ne]\n\t" >>          : : [a] "r" (a), [b] "r" (b) >>          : : ne); >>      return true; >> ne: >>      return false; >> } > > Based on the information provided in this email thread, > it appears the only concern when it comes to comparing a > pointer loaded by rcu_dereference() with another pointer > is the possibility of compiler optimizations. > > In the specific case of hazard pointer hpref_hp_get(), this > function does both loads which are then compared with one > another. Therefore, it is not possible for the user to > provide a comparison value known at compile-time, except > in the unlikely scenario where the hazard pointer would > be const, which does not really make much sense. > > Therefore, just using rcu_dereference() for the second > load should be fine. > > Thanks, > > Mathieu > 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 completeled the load of that poitner: node = ... // t's value can be computed here, since the value of node is known ... node2 = ... if (node == node2) // just a control dependency, doesn't prevent speculatively loading node t = *node if we can force the compiler's hand, it will generate this code which provides the necessary ordering at hardware level: node = ... // t can't be computed here since the value of node2 is not known here ... node2 = ... // t can be computed here if (node == node2) t = *node2 Kind regards, jonas