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 4FD53C369D3 for ; Wed, 25 Sep 2024 12:03:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A44B6B009F; Wed, 25 Sep 2024 08:03:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 354036B00A0; Wed, 25 Sep 2024 08:03:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CFA76B00A1; Wed, 25 Sep 2024 08:03:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 022AC6B009F for ; Wed, 25 Sep 2024 08:03:10 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B145A160CBF for ; Wed, 25 Sep 2024 12:03:10 +0000 (UTC) X-FDA: 82603124940.06.EB5C5CE Received: from frasgout12.his.huawei.com (frasgout12.his.huawei.com [14.137.139.154]) by imf25.hostedemail.com (Postfix) with ESMTP id DB9F9A0029 for ; Wed, 25 Sep 2024 12:03:05 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.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=1727265728; 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=JT4ia7rX5Cnn9Xxntp9/DL3U5Pq2TLsdweBRljNlmrk=; b=AAB9fmIrDsR7/3xItOIKBQ7lhkt5Tzgx71oH96D6RuyTwN//gYu/e9OJa0ezS9lK0USmXN g9QB3p8eWDIXXx7TzrObgyiBUZjZxudMawwSc+cBdy15VDPdC34bFav1erarXjFwGw04kY COHTcDPnIz48z3GrHlgT++SRbpEC8KI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727265728; a=rsa-sha256; cv=none; b=U8Em/c+//RqFSQJ3qN7xxAP0GpMsu/gb/2eQBbr+l5S7LySJLN36wtOZ91POsyt+8ZRUl/ mqwlLpgpjdPR9ksAJJcniNpS6Sr3TVXkTIu55W/5wsiRhvXtxtnFDxkqshkrFE6Q8SckPy DExMgTs29E0ssg3jOJuye0BBx6KJA4U= Received: from mail.maildlp.com (unknown [172.18.186.51]) by frasgout12.his.huawei.com (SkyGuard) with ESMTP id 4XDF8640LLz9v7JT for ; Wed, 25 Sep 2024 19:37:26 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.47]) by mail.maildlp.com (Postfix) with ESMTP id 45BCE1402E1 for ; Wed, 25 Sep 2024 20:03:02 +0800 (CST) Received: from [10.81.208.14] (unknown [10.81.208.14]) by APP1 (Coremail) with SMTP id LxC2BwDHWDDn+_Nmp9abAQ--.40229S2; Wed, 25 Sep 2024 13:03:01 +0100 (CET) Message-ID: Date: Wed, 25 Sep 2024 14:02:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/1] hpref: Hazard Pointers with Reference Counter To: Mathieu Desnoyers , Boqun Feng , "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, Will Deacon , Peter Zijlstra , Alan Stern , John Stultz , Linus Torvalds , 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 , rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev References: <20240921164210.256278-1-mathieu.desnoyers@efficios.com> <48ae741e-98aa-49d9-b677-6c4f8fd1bcb0@efficios.com> <07c9285f-44a1-486a-8390-0c63cefae35a@huaweicloud.com> <38b04b86-1e85-40f0-8174-3c8ab29cbcaf@efficios.com> From: Jonas Oberhauser In-Reply-To: <38b04b86-1e85-40f0-8174-3c8ab29cbcaf@efficios.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:LxC2BwDHWDDn+_Nmp9abAQ--.40229S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Ar4xJFW8ArykWw4xZFyDAwb_yoW8Kr1Upr ZxKa4q9F4kGF4Fkr1xtw1UWFy0yF1ftFW5XFyvgr1fAa90gry0gr13tF98u3ZxA397JryU tr4FqrZxZasxJa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxV AFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWr XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVjvjDU0xZFpf9x07 jxCztUUUUU= X-CM-SenderInfo: 5mrqt2oorev25kdx2v3u6k3tpzhluzxrxghudrp/ X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: DB9F9A0029 X-Stat-Signature: neqjwmpbgj4gt6zrrptxipsf6jqj5jur X-HE-Tag: 1727265785-538011 X-HE-Meta: U2FsdGVkX1+nZbviSwjNaBanDzsKwubTNL6HiNxTMMpEX7klo7QCO3CP+jnknN1+6iGKcoYW44yUDwc/Oapg3AA5CAHt/g2HviOrqrOaOjGJLQAiaLFVhGZqzjoRfp12umlaGPxEIjA46qWl3FByXxoSj70iwdb5UlT87gZlC5CoUeik2lnI7+0Zv1BvJoolep5RPA8L41RpN9cXxJOOXXiVEGpSpkR5PmUIm3fCru1a0ggZPghjPktTjr9nf/BKSxQvO5TaCR3Ro4hVOCCOUciv0y5hDLU9wb+gMcnF6+bpV9V0/2q+/7Jd9rZ0SEAZW2xSH4/1r7TNZgaBJ1YrB2NhcAJIxXf5X8zJe5UZfxN1eegiX3vLGaX5izbdwoNDAi6ST9jvXqE859uFmOKO0SQBjpuDcBMPbNUj5B3Jxro1AyV7GcnbjjmNNYHeyWe5tzwyDvFo+zZu4NZXEjpQFoLRZA8u3ISB0sI4htAteo9tBQIqSr7WEL2DUoMf0tiyTQz2yyf5Fdx/xdmQ+gb5rKx71BCJZp+pF3ozY458eE51AXooblIVPnw95TIVMJB/Ti1S2q+QU7lNr1JFH9HIgfhCq9r0K2VtfwnamVOb1iwkSbd13Ca0lIiQ4ostGBnH2cvJtTLBzA0zpbY6+UOd0nSZjqV63Ubho5qx2eGmoeyHFWsOuxBQVOTe6TqFOJGKFO1BvcNjVwVHI2JwDhZx+gN8IvofYDDW0z1vo0WrDooC8ePOG3bKLZElU2j87ACmTaB5aKqH0GR0YFMAAoepj3lzXXolz7sB/HsWwG9WV7yfAoRoLaK3+6mZXrNxHY5poyC450onDk8XAvCdugm0PgSJxLvy0ZimIDBj7ILX73nw8wFRkj/OU3hhHjVLa1Goj3VXoZmXXkOzYlmyz/0v5LjorK5ygBdK2zMrUkT6S9yfbeUWd2Lh8WoQu+NWWJGPIKELlCswnm3jxmmi+ob gnmqeHNj LP+g83gkANLKQDNIpMq8+Hp4FTDtOBPiWYOqH9yZmw4koKamP3M6gsQg+xHHzmFM94BoybA8CHw+66acnIcLjfyuEcMSqrq3VPQF9bmCPV5VJusaNInHJqm1VN1jufkYQOhWQEI0hfflrYH8YLLdsXLUMzwDYPb4AOlUUGZM7X2xzsQcnlIUQrp2/fd+FHO693/TqHNMVALUokk8fhxc/SoZIg+O7ZXXRp7i3abnczLxEUMSeWN/qGOJ96zHmK8JpC/uO 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/25/2024 um 1:36 PM schrieb Mathieu Desnoyers: > On 2024-09-25 12:06, Jonas Oberhauser wrote: >> >> >> Am 9/25/2024 um 8:35 AM schrieb Mathieu Desnoyers: >>> On 2024-09-25 07:57, Jonas Oberhauser wrote: >>>> Hi Mathieu, >> >>>> I haven't read your code in detail but it seems to me you have an >>>> ABA bug: as I explained elsewhere, you could read the same pointer >>>> after ABA but you don't synchronize with the newer store that gave >>>> you node2, leaving you to speculatively read stale values through >>>> *ctx->hp. >>>> (I am assuming here that ctx->hp is essentially an out parameter >>>> used to let the caller know which node got protected). >>> >>> The following change should fix it: >>> >>>       cmm_barrier(); >>> -    node2 = uatomic_load(node_p, CMM_RELAXED);    /* Load A */ >>> +    node2 = rcu_dereference(*node_p);    /* Load A */ >>> >> >> I don't think this fixes it, because IIRC rcu_dereference relies on >> the address dependency (which we don't have here) to provide ordering. >> >> I would recommend either: >> >> -    ctx->hp = node; >> +    ctx->hp = node2; >> >> which fixes the problem under the perhaps too weak assumption that the >> compiler doesn't use its knowledge that node==node2 to just undo this >> fix, or more strictly, > > As stated in Documentation/RCU/rcu_dereference.rst from the Linux > kernel, comparing the result of rcu_dereference against another > non-NULL pointer is discouraged, as you rightly point out. > >> >> +    ctx->hp = READ_ONCE(node2); >> >> which I believe makes sure that the value of node2 is used. > > I am not entirely sure this extra READ_ONCE() would be sufficient > to prevent the compiler from making assumptions about the content > of node2 and thus use the result of the first load (node) instead. > It would also not suffice to prevent the CPU from speculatively > using the result of the first load to perform dependent loads AFAIU. The reason I think it should be sufficient is that it forces the compiler to assume that since the comparison, the value of node2 might have changed. Therefore, simply using the value of node at that point should be unsound from the compiler's POV. But I'm not a compiler expert... So I definitely support uneasiness about this construct :)) jonas