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 D6A50CF58E4 for ; Fri, 20 Sep 2024 07:41:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 161E86B0082; Fri, 20 Sep 2024 03:41:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EB936B0083; Fri, 20 Sep 2024 03:41:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECE376B0085; Fri, 20 Sep 2024 03:41:52 -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 CDDB06B0082 for ; Fri, 20 Sep 2024 03:41:52 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 75F2B80128 for ; Fri, 20 Sep 2024 07:41:52 +0000 (UTC) X-FDA: 82584322464.06.45B90C4 Received: from frasgout12.his.huawei.com (frasgout12.his.huawei.com [14.137.139.154]) by imf27.hostedemail.com (Postfix) with ESMTP id 2BC824000A for ; Fri, 20 Sep 2024 07:41:46 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.154 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=1726817996; 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=KDSdPWX8yeWTBpf5IEvpq+3L1kg3s4ZymLNA5jrQ+AY=; b=r8gFA+8YaJPosHh3LPtsiGcEUeOVHiwFeT2CHKXWtoG714fuzcjajvgsXphjwPzDu9IAl8 usmGiYAwHtPiFgS3CFtFYr96DDymUjhDKJ/EdNdxx4pjlTW0JzZf/8YJJsSJusxt4d4KNb UGv6dGe0fUBYW2jJsn2tYHN2xvsH+dc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726817996; a=rsa-sha256; cv=none; b=4AMUukN9oir3xxIcaAakri0gEMsvgvyuCbcuwBeFQeu1TRwoF0cUTPrxt8q6TMCxqgAr0j di16HSEDsGx/fPz4PgSSxosbuzoIwNpX9R/YHG2zxAULw9RPLHrl8G9fr5s65RpCLeX/P3 ztbpvxcliRFYTHV0oPJAR+KzjrSLqfU= 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.154 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com; dmarc=none Received: from mail.maildlp.com (unknown [172.18.186.51]) by frasgout12.his.huawei.com (SkyGuard) with ESMTP id 4X93b22JMzz9v7Jg for ; Fri, 20 Sep 2024 15:16:14 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id 6EA1E1407F5 for ; Fri, 20 Sep 2024 15:41:33 +0800 (CST) Received: from [10.45.149.49] (unknown [10.45.149.49]) by APP2 (Coremail) with SMTP id GxC2BwDnlsceJ+1mNllJAQ--.61641S2; Fri, 20 Sep 2024 08:41:32 +0100 (CET) Message-ID: <55975a55-302f-4c45-bfcc-192a8a1242e9@huaweicloud.com> Date: Fri, 20 Sep 2024 09:41:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers To: Boqun Feng , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@vger.kernel.org Cc: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , 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> From: Jonas Oberhauser In-Reply-To: <20240917143402.930114-2-boqun.feng@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:GxC2BwDnlsceJ+1mNllJAQ--.61641S2 X-Coremail-Antispam: 1UD129KBjvJXoW7try3Xw45KFyDJFyxGrW3ZFb_yoW8GrW8pr ZFqFyUCFs3JF4SyayDXw17urWv93Z3tFyDJas3uFykA3W5GrWrXF9rKryjvws5ArsY934Y qrW5KrZxAFyDuFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIEc7CjxV 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: qoykpxkhfqbyfch17id6je454fjf56ei X-Rspamd-Queue-Id: 2BC824000A X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1726818106-828890 X-HE-Meta: U2FsdGVkX189u3AGh0udD/5T9GHwTzBhuTq0dwk/rRg1Byv7bMCoZC7uTvOk3sTbTwFq9QwNgG29Kgn+u4yzu1+wvvD9t73u5RDV6ZBysonAqTxIthfn+Rv94e2AzH0xx2djtx0Q9ATcjVfzCC5Y6HYWJe8nH/JHWjPWT5H62w3qV8h8mZp9ok3zTH7Uusr66mkK/p3sERL+3Bjh5MCBIIVAuY/PnkLYPU5kH5AO5tkWA5rIMxhFn3AYp/MtfbIAtTIL7rf3pnEQBc6cXo7WsQYPrLxTNhnubTbZ0fv6BJDqblyA8GU5Tom7Uypt4kGmMhWFvswtfrh/jM0nD1OVb6e0BtqPSYrE8ripwF7w+/JVm+soMjW0gtymEU2Z58iSCP5RaNkxYroEnQcDsoxLjvt92sVphzA5Y3PW+xiPU1DWJSI0tXkcpuJW35RLOv1L/alRIb9739dLJIYiEXHPx8RNOzqKm/3YoKxmw0QLhmikG7VGdGhWb0DTK+/uTu2oIDFZK1AGqNXHN0muPYkAl6C93qXyEDMtr4t4S25YqbPU03oHqd3UQ8j1V0ddT2sjSqfsieyLe5+FWdgh8nzGf+l6Zu+Pe2RRdVw5ld1TVe85i/hKP7iww2XyJX5tSpcjO3qHvDR7/8X/bSIGrH9hZnD6duRehC7HcjNt6si+xzyq3xDNfHQUI9g5LHuldvjkc4pzLwzqaWswdmKxNzkQP5WFhbAebn+w8pZrIlklitc6tV18cuKMESkjdczGxviCEPcVB/9yGoiHIsvPLIPMC4Sk2s4WBMCU+zo5Ac0g4RUgVhta40fA2LqIdSRSfvp0c0+KCv0t+tag88YgzTLegy8Np1M3gDnjeIeawyVqKSX3fkZ7Wk4WiOilrRWf6130hHpI9Xtve1evIuq28Oh1Sx2aVsaj9CuswUpEUFk6J8WrMia2/Rb6BvnknzAUPdy0PTfq2ceONcIpCM7DK4l nzhxLzS5 A5eRdOzMXyJxsKJU9p/ojdw3EgBOzMccEgDlWuCff2nWHk+fqVN3527nzR60HLXW6oewP5jV/0Vcw1MUS+no7vAJthvrogXP3gX5/6l/XliJIWtR7llPmLLHpcn8zWn2FImDJZ12eURwlnJQHmxDXKaZ5qyfi/afAxFfe6eGZsXUVUseIztvgfLjniUzn0vNmnqhIPMh3Rstj/eIRS1IElMMI+5uK+RtOZmZPc6RbijKa2u4= 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/17/2024 um 4:33 PM schrieb Boqun Feng: > +static inline void *__hazptr_tryprotect(hazptr_t *hzp, > + void *const *p, > + unsigned long head_offset) > +{ > + void *ptr; > + struct callback_head *head; > + > + ptr = READ_ONCE(*p); > + > + if (ptr == NULL) > + return NULL; > + > + head = (struct callback_head *)(ptr + head_offset); > + > + WRITE_ONCE(*hzp, head); > + smp_mb(); > + > + ptr = READ_ONCE(*p); // read again > + > + if (ptr + head_offset != head) { // pointer changed > + WRITE_ONCE(*hzp, NULL); // reset hazard pointer > + return NULL; > + } else > + return ptr; > +} There is a subtle potential for ABA issues here. If the compiler replaces 'return ptr;' with 'return head - head_offset;', then you do not have an address dependency from the second read. In this case, in ABA, the first read can read from a stale store, then the second read reads the same value from a newer store but only establishes control-dependency based synchronization with that store; any reads from *ptr could be speculatively executed before doing the second ptr = READ_ONCE(*p). Therefore you could read the object state before it is properly reinitialized by the second store. I'm not sure what the most efficient fix is or if you just want to gamble that "the compiler will never do that". I guess either READ_ONCE(ptr) or a compiler barrier before return ptr might do it? Have fun, jonas