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 4DDE9CF648A for ; Fri, 27 Sep 2024 22:18:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1D186B014A; Fri, 27 Sep 2024 18:18:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA5C16B014B; Fri, 27 Sep 2024 18:18:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A46336B014C; Fri, 27 Sep 2024 18:18:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 837346B014A for ; Fri, 27 Sep 2024 18:18:38 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B408F121684 for ; Fri, 27 Sep 2024 22:18:37 +0000 (UTC) X-FDA: 82611933474.05.D315C99 Received: from frasgout12.his.huawei.com (frasgout12.his.huawei.com [14.137.139.154]) by imf17.hostedemail.com (Postfix) with ESMTP id 697DE4000D for ; Fri, 27 Sep 2024 22:18:33 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf17.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.154 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727475498; a=rsa-sha256; cv=none; b=AkqL+uudinh0RQw6QzygBj8X/g4o6PM3INEx7exCOev9NUTRaxQFP5wiiOlYpaIBK3AmVo xa00XtzxEvE9twtQ/nOslJNeJnMqrgNgIOKlkuX4PWbzaaFpUCSVo75muWvrKRIjWq9FvM A1tMDQ+IUATdxGYDCFY+8TU098L+R9U= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf17.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=1727475498; 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=q4jF70GZK4jvFJQAryIU6SigGrKO+/AwHxhGQ9kmD5U=; b=UXv9WgDlVBNHQh771AP6GlmoUYgxSNckJboBmKfEHUqE+N8bmJ7mEPhsv0J086uEPh/bqB ohk5jYVNUc1s1zwMfQq+HmYMms8G9+8YYHKSn0IgoaikHCd4S2RcxOXtseqU43koOWEB3m 9U/z++/UCxztz4LzBHOVI2TVYhmCwp8= Received: from mail.maildlp.com (unknown [172.18.186.29]) by frasgout12.his.huawei.com (SkyGuard) with ESMTP id 4XFkjF1N2yz9v7JT for ; Sat, 28 Sep 2024 05:52:49 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id 23493140393 for ; Sat, 28 Sep 2024 06:18:24 +0800 (CST) Received: from [10.45.147.63] (unknown [10.45.147.63]) by APP2 (Coremail) with SMTP id GxC2BwD3pscgL_dmmwLIAQ--.52307S2; Fri, 27 Sep 2024 23:18:23 +0100 (CET) Message-ID: <4ed833df-54e6-454a-ab1a-73967cc51054@huaweicloud.com> Date: Sat, 28 Sep 2024 00:18:03 +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: Linus Torvalds , 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: <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> <62508c1f-66ca-450d-abb6-236ca3b9096d@huaweicloud.com> From: Jonas Oberhauser In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:GxC2BwD3pscgL_dmmwLIAQ--.52307S2 X-Coremail-Antispam: 1UD129KBjvJXoW7KFyxCFWkAr1rtw4DAFyUGFg_yoW8uw15pr 1kKa1UWFZ8CFs7Ar17tr4jyFyYywn3Gas8XFyUWa4DA3yqqr1SvFWjgF90g3ZrCws5Jryj qr4UJr93uFWDAFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxV AFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWr XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU0 4xRDUUUUU== X-CM-SenderInfo: 5mrqt2oorev25kdx2v3u6k3tpzhluzxrxghudrp/ X-Rspam-User: X-Stat-Signature: wkhf6okn31zcdr3kk8qqqo848z1xndce X-Rspamd-Queue-Id: 697DE4000D X-Rspamd-Server: rspam02 X-HE-Tag: 1727475513-10415 X-HE-Meta: U2FsdGVkX1/hsVYx7AvjPz2jV7Cfqx8NFQGHEYQh6sV/12R8Ey9+QhsTyapxqMWW1I9nAPhm2WOuUCPq0F5kzKPrT8Naqp0CFP6AAa/4KecuPIf3rhg4zev8eCzZvSYak900rS9O9L+mvRx2ydEmm+d8tWDNZvhlgHKdC5zu3Ggy0HmGPhLYGV56aIBG5K9XCFu2NZyhu0fOgNqysCLhSPkx0HNBHraQD5mA7MUGtK1+rMUUS+pDp4CXZuNgKx6jxVmm5nN/u259uTHIHarSKwqTMpYQkWQW5EadFVlkG0xgyaLbRnObh2jJLl19HdX+Rs2Pf4UwtOpvUj/jzNCoN/Wswytl73YfbCi17M/ltpfSX9SAL5R7eC2gnIjTUnBcRFShDQVLDnwUdy+QQx2jQv3ZLJ0y1CeP1LYBuniLgTKTxn3SzU91Wnd8Z6gYxp1FxNQ8P6RSXUJ6ImSICKlebq3MOtdKiXyz4IT8PiGpYhjYqesJVZmOlhLaolAlLOpUCMv9Hn2BVsU8Qjn5aKDxJGe0JEkfD7EMXrNadgvlfqaj83b1JxrSMrXfZq2z7eeq2d6Zg97CTdVxKQw+7DbyG8v4Eyqhk975Rlu9OJPLnbVwsjMV1lO2xSM36/JxENF7+3m412O8AtKMT8tveiTMb5Lwb2GYVn4HSIlUkIRA8DOOZ+P/hCEIU9C+mL3WuP17HpTeP1+1l7V1QBTf1VlKEqWRBFYS19H+bfJCgKd8tO8TvbhW+oIzwQCq9d5FunZzCszkX+GcKsZNjuK49XA2iGbtB/OltYd+0jkDeo1HI0JL2YVi7N7fp7aI5fTIFqUlAyc2GPXqk6Re/WWmmWYM/6bNfx/K5Q2wI6T9tpoYvPtlXddlQK+cHdZEAqZW+vICCseA92j9KB8fH8O5E3go9A1sRfaUjJLsHB9dYZTZtaWhpSryFsCHQ9kVYh3t/0aa9R2WoWRKgZ1Hy+6dxkz AkeZoE66 Ty7aLvThgVSPGaLC2ADRfMHB0QYeO+w2HRBzl9EYTEkbbyBBEs9Eoy4LaO1XB3lRR92r2y2KsbOtYY3ldoNz7PRVLgF32tY/abT7UTbhbzcpS6ZQGORXwrXJ+VHYFT0CcGdE3svx3tqBXbQeKt5SX+av1GX93Pc4Zv9o0PzjYeB13KNQfYr9F1/HWkd3b1odUrzQUIqpHWD20mmF+VI/C+47OZmfSjF+hnx3SH9OtGTpaPM44rtje8wboPKn6HQ94DUX9+5gqElHgUY5J4gU/+CAPN53of4acafzH8I1q6VF7s1AbUvk8ijVOHJzZFKDgMBxz 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/27/2024 um 10:10 PM schrieb Mathieu Desnoyers: > On 2024-09-27 21:23, Jonas Oberhauser wrote: > [...] >> That idea seems to be confirmed by this (atrocious, not to be copied!) >> example: >> >> int fct_escape_address_of_b(void) >> { >>      int *a, *b; >> >>      do { >>          a = READ_ONCE(p); >>          asm volatile ("" : : : "memory"); >>          b = READ_ONCE(p); >>      } while (a != b); >> >>      // really really hide b >>      int **p = &b; >>      OPTIMIZER_HIDE_VAR(p); >> >>      asm volatile ("" : : : "memory"); >>      return *b; >> } >> >> This also does not generate any additional instructions, unlike just >> using OPTIMIZER_HIDE_VAR(b). >> >> What is the advantage of defining OPTIMIZE_HIDE_VAR the way it >> currently works instead of like above? > > Did you try it on godbolt.org ? Does it have the intended effect ? I certainly did try and certainly read it as having the intended effect, otherwise I wouldn't have written that it seems confirmed. However, just because my eyes read it doesn't mean that's what happened, and even if it happened doesn't mean that it is guaranteed to happen. > By the looks of it, you're just creating another version of @b called > "p", which is then never used and would be discarded by further > optimization. > > I'm unsure what you are trying to achieve here. Simply put I'm trying to let the compiler think that I leaked the address of b. After that, the memory barrier should let it think that the b after the memory barrier might not be the same as the one before it (which was equal to a), forcing it to read from b. However, I suppose on second thought that that might not be enough, because the compiler could still simply do b = a right after exiting the while loop. And that is true no matter what we put behind the while loop or before the condition, as long as the condition compares a and b, right after it the compiler can do b = a. Just took me a while to see :)) I'm not sure why gcc does the b=a with the normal OPTIMIZER_HIDE_VAR but (as far as I read the code) doesn't do it with the above. Maybe just a weird corner case... Have fun, jonas