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 79138CDD1D2 for ; Fri, 27 Sep 2024 19:23:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5D146B011C; Fri, 27 Sep 2024 15:23:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0C9D6B0131; Fri, 27 Sep 2024 15:23:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD4FE6B0133; Fri, 27 Sep 2024 15:23:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B08BA6B011C for ; Fri, 27 Sep 2024 15:23:51 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5F892407FE for ; Fri, 27 Sep 2024 19:23:51 +0000 (UTC) X-FDA: 82611493062.26.3829971 Received: from frasgout13.his.huawei.com (frasgout13.his.huawei.com [14.137.139.46]) by imf22.hostedemail.com (Postfix) with ESMTP id 20472C0017 for ; Fri, 27 Sep 2024 19:23:46 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=pass (imf22.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=1727464967; 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=IQZ9RzhfTWhIh1P8ltwK6uvMkoKlCwOBw2ewrg2s9G0=; b=4otZoy4QsmD7lgYypRbZEpcFk5x3V8QaSmuVc8e/YEO6SyKRDOiGwww0XUMMYZ4h91Kvix Wst7JBzLAxfytoQ6kfgD0ZPHOJ3+pP3b2cTMfZYcdaZt5w37rFUGNzYbEZHddRyWKgocFo +P3+csNIDlhyPiCkKXZkXTlIyrPut3s= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=pass (imf22.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727464967; a=rsa-sha256; cv=none; b=a5rUlv9/ax/gRullpUpR0g2etmDqIyf4RJR7zVufZdZoaT6rqWTVkiSGG2KER9/0MOsp8s zxk+R8N+MysVRO3eJl1KJf7X/B2Hy2vYJFnv0OmHCctnkd7QIY2H1C6t+HmgeYPX6Qx2bf Ot6Jwc+qvVBXnz1pEg9anfEI+VYUoiM= Received: from mail.maildlp.com (unknown [172.18.186.29]) by frasgout13.his.huawei.com (SkyGuard) with ESMTP id 4XFfyM6xdcz9v7NS for ; Sat, 28 Sep 2024 03:03:55 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id BD70D140393 for ; Sat, 28 Sep 2024 03:23:37 +0800 (CST) Received: from [10.81.203.162] (unknown [10.81.203.162]) by APP2 (Coremail) with SMTP id GxC2BwBnFscqBvdmpgHGAQ--.52397S2; Fri, 27 Sep 2024 20:23:37 +0100 (CET) Message-ID: <62508c1f-66ca-450d-abb6-236ca3b9096d@huaweicloud.com> Date: Fri, 27 Sep 2024 21:23:20 +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 , Mathieu Desnoyers 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> From: Jonas Oberhauser In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:GxC2BwBnFscqBvdmpgHGAQ--.52397S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WF48Zw4Duw13Kr45ZFyDGFg_yoW8ZF1kpr WagF1YgF4kAr4Syr1Ivr4UZFyFyrn3Grn8Cw10gryqv3W3GF4xuF4fK3y7CF9rCrn3Cr1j qr129a4S9wsxZa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I 0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWr XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWxJVW8Jr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07 jzE__UUUUU= X-CM-SenderInfo: 5mrqt2oorev25kdx2v3u6k3tpzhluzxrxghudrp/ X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 20472C0017 X-Stat-Signature: yyn961b1xa7pome1c9d9iyo4nmw6snzz X-HE-Tag: 1727465026-483315 X-HE-Meta: U2FsdGVkX18weola07OeTJ2zRzDGgtHvDD20WjleMhSNDOELaKBb914Ne32ZlF7qLBSdnq9LoZSFhCoqtUuTZbzHJj1Von5eKwYleA7iCSLx4RIeUKdL6vTtALE96pxAKK/gzJpE3McZ5WfK8+c3VWK3nPeXZSXW93wzXlUuBQ00iCH3Dn1BvWq9YV10jiPSXj+aeAxbvGUBb6mQ9OuOiFZWkefO6WCYN/sws3WTbhDFJRNIlmRXJm1epIfgMrFyudttTRqhUC3yYwnjcJnmBumBAneVgO8f1DrOt0pbiRMOPv+Dh6kn3TohRhRNF4uUd7thUVXNZi7lrvV+rIhpO7IQFzSP65Grk+i6SlNHsW1k8lgMCT6zXJEZjAnDfqa60bBwBBRdzhj1E3AsiVztRAcUBNMdSEPbCC6goAHMSxXUx6plz1HKwvfmE7+ueeDQentSx/hMp03nWrxZNfVGLBxHl53yHMM6zg2O5Ty0yZ6ICxiBhgJ0pZ+GemyYgmul6AzeHk7y/LSQoo2Oy2j2MPieBk0a11ZbW/D26r9IT86vdicO9zjs3fj2j+Am0i7wjCfslYAOE57lViytR6hQqoAMUF+C8IspQBEdC00f/jUpdEl/mBtmr6Os/KOp/HnYrQBwJSoMvqIfP+UANe901rEkFXCcGkby+VeoWGDDDNZe92PbyXR6QOeLwxRJEv/aO0fT5Z2s0D+I26WOMX0LLosQFvCjwV22zECV+Xhu1lLdcEGCr+AD9z4AQZOQvthIp/Ibpe0CYyNKeTWl4VEZ+EHW717QxgeX+ekwvt9hJDwkCxsniolGCN4d0H7anDY7U+S4xsPsqeGiU0q3skKFsSkuyTY2XIPu/bKGt2W4rjVhxiyyesE4szmoXIG4pqYCQ0y3wRwTyHDkPvQClrGoKxmanyaGi+WilyBzKoZQiOau/mWcgkNQKdNLIfNgETA8vn0WW0dgdVCyWzeXRmj DCr2vDo/ P6136U9dnzANjDuRhkygeDPccr5yNaA5vM/KsGsoxRPjYyVRLE4vXQGUpVVcjwqkr49Lmt1S4iAqG9i+WPUNQ0kFFliBZbkqPJ3rLERNVA3gwua/c4a6DZeZxEvePxK3tpxtCaWH0cfvh5/byBNFLyzAM7LxqiwoWCOitClBDEqmtHvuqTOGdbMl/7uyqEFWAMtM+enFO+5YUozcOoF7T4YTYAULN0g2kK5rd3YEJn+5PeDE= 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: Two comments inline, Am 9/27/2024 um 6:38 AM schrieb Boqun Feng: > compilers can replace 'ptr' with 'head' because of the equality, and > even putting barrier() here cannot prevent compiler to rewrite the else > branch into: > > else { > barrier(); > return head; > } > > because that's just using a different register, unrelated to memory > accesses. Yeah, that was the solution I had in mind. My reasoning was that from the C abstract machine, head is still a memory access, and the barrier() should make the compiler forget everything it knew about the value of head from before the barrier(). So I had a gap in my understanding of the strength of barrier(). Can I understand it to mean that the compiler can do escape analysis to reason that a volatile asm code with ::memory can't possibly be manipulating some variables (like head in this case)? 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? > On Fri, Sep 27, 2024 at 03:20:40AM +0200, Mathieu Desnoyers wrote: >> I have a set of examples below that show gcc use the result of the >> first load, and clang use the result of the second load (on >> both x86-64 and aarch64). Likewise when a load-acquire is used as >> second load, which I find odd. Note that if you use acquire on the second load, the code is correct even if the compiler uses the result of the first load. That is because the acquire load will still synchronize sufficiently with the second publishing store after the ABA, and then we can get the right data even from the old address. Best wishes, jonas