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 42E6DC369D9 for ; Wed, 25 Sep 2024 12:48:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B95836B00A7; Wed, 25 Sep 2024 08:48:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1DE86B00A8; Wed, 25 Sep 2024 08:48:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 997776B00A9; Wed, 25 Sep 2024 08:48:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 788A96B00A7 for ; Wed, 25 Sep 2024 08:48:21 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3699E1A0BF9 for ; Wed, 25 Sep 2024 12:48:21 +0000 (UTC) X-FDA: 82603238802.25.03B3AA1 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf30.hostedemail.com (Postfix) with ESMTP id 2D64180011 for ; Wed, 25 Sep 2024 12:48:19 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=VqeA6j3w; spf=pass (imf30.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727268379; 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:dkim-signature; bh=mQO8hLyjkJ3HX527AcCOXCJrMEAdmPV4J/TcUNelpVs=; b=IXSkyG0fWJpjPdmwMpItbtEpqdVeJO7sdLbVAvUTvEXm850AWBSTq1c3jIXUB35qbzlska QIanpJBAXA6+DrO2jvGGvVYm6X3pe420m312FtFnhtDS1eXQ+kApJG/22n5L3H6eRSnb7d ReIvUdO+BNHbL6mLTFBybdFDcspVlkc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727268379; a=rsa-sha256; cv=none; b=3pJm6tQqnAYWuzK+zcah8ziBHPlc7zAicNp3BMUhdlGXAqCOOS69iYDYaPOO+nLWKKg9St ecZqZNqHOa6sVm3MkqVhRH16tZLuVv/9PN4rp7FBSPqMn657H2ZG7d+Q5ZyMNeefiuydlm W0WZ5anTcWZIHJLCWtxgncSNh68aEmw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=VqeA6j3w; spf=pass (imf30.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1727268498; bh=24v3d1jjV4GAVX62MeV1ZzpVMnN+aHy8vAKvEJyK3Yo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VqeA6j3wW7L0gZavAW9VbhmKfkwEO9YJWLS97HC+4BVvFvj4UDFor1HyoQjDrl0vN L8+alwtwKCELhjqbzBYXXxTd/OxnLTVA5wEaFsJvrZm8teAJ0wlK3FdbbpZ2aUmotj u8NM0qv70aopRwRm//IlN99soxfiD+heN+y3LrHJCo/hLP1Ju/SR+SkHNbqR++Rfag S3ieVP7cfVC6VsqWjLdlcQkrK3oIuhYNOToaLCMI3XWy3gT/sgUc3hBRETx2ZYhfUM VSnySAm5d4+f6sBELPNgGQWT2oYhIyiUW33i0NqiY1l0fBc7SdIfpQlxX+IQbdssYG ea5EBN1bg0hLQ== Received: from [192.168.126.112] (unknown [147.75.204.251]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4XDGjg4b5Hz1M43; Wed, 25 Sep 2024 08:48:07 -0400 (EDT) Message-ID: Date: Wed, 25 Sep 2024 14:47:26 +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 Cc: Jonas Oberhauser , 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> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: jrspprycdtp9egfyn1nz6xn54b9pisnk X-Rspamd-Queue-Id: 2D64180011 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727268499-60444 X-HE-Meta: U2FsdGVkX18VE4qJG1Lm/PUOw4O/vYNbAES4poSdxe+D7fd7cv/lDfjfZHjYYgxjmsVPfvsnHYrsnc5svJzqVWV+SeHBgY11g4yrTlWcXlD+UAhmGmm5yTDBalUXNSUvlZfTnuAWYYOoJVfh0SgZew4z1JFZ14BpuKWjK7YKUAfJhOLEOqOcy4kgOWxch4MU1kxGZw5zXPMVFbnD0JdGWY5zfF/nsmZ5Sclibs/WVnVbb/YsKdYhoTm7sMgrbOg9snDD7E5rMOchXgQzodVUyVEwglOMYO7nvShYlmbIBlOZbIcI07OK3i++t+Q3s7p3ks+8XfgN29sa0mA5gU1PrqS01EZS1//9fkTOurP16uYgUaidjCBSexiwOk+bIn0e/jFQTS13Bm6tRIe2xRe0RXvOHMyQomacKJhEA17Nn6REExtMpTShjOdSDIyrzozZlbv1OYIRc5+Z5WWitrNGpTi/Afb2UxEc8EvAXe1teB7783NpCTzXwFpjboOdRH5DXYoYaugSjHMKfc6Pp70RGhVVzsil1Tn5v0U0gLRuRBMLO85ryO5NyeLloOUbACWupbRveP1Pdua9bbQYwejkfgfoovsf9pVXzWUW2jgO/hDhoKCDrBNyriRhRwgc/uvtL+/fNevUn9RrHae5SkN7k3VyMr6AX4w9xdZ46PGeWrZE/e3oVOyeM+8OL3vQBJNCWFMg2MHPBcLZk8AK5QRvmGsmpD8Mk1x5PezQdRqSbVlMvfsUviDmo3BRykl1P05/0+dUBkyzhXiNiyWrB9auF/DuQjYr+DsmmqM1EQ5TozA11lLBkcVq1QFlwAqcQPxyL8RngmSRz5wOBIjRNZDcyTJbiZ4Sra99ME5fU1DWKjXBPZXaaBUy1Qe9Ev09W2zja8bDOnNd3YGTf4KOcpwh3GD7iYUfSUV+GEY2GQ10Un0OUNS1JzsTFZacIL0B3BXRjfBn0PWlwPPV32Z0Ynn ZgjVQc/R CZLuPQRC7ByFphfBj8Adg0opwEY0AgVwZJXNtoTCl8WWIemXJudLZSdUEwkvNHc42KOrDUDwKeY0+DN3hZl5Fral6bkDlra9dMxyS05ONu6tsO4+2pKAHMqob/th4AGNUNVQh4/OorDuY/94j/lML0VFo2M4JBD91Q0UoZ2sjarCkjX+IVAUchkFfm5w9rS8nk9lqZYbuQxenxYjZ83v+knDJTrp3hAzwm7jZzyhPFYpUBvjZIONyuLUP4agN5lNy4gFPKTKGUKVWPj9ETm32kVDQt+y1khhsSdu8JCVbHhZKQCTJK2h0PkgRfttYuxRsYpV4K0VE4cRWbpoMRjOhZQ8Qz3qZODbu2URz0fl8z0dfwMgYQfUpyHqVlC0Z0Dc/yJADxl2rbfpO/yyflruOPORnkUSwLo9Mh1ALQITDesNWjX4= 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: On 2024-09-25 14:16, Boqun Feng wrote: > On Wed, Sep 25, 2024 at 01:59:06PM +0200, Mathieu Desnoyers wrote: >> On 2024-09-25 12:45, Boqun Feng wrote: >>> On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote: >>>> >>>> >>>> Am 9/25/2024 um 12:02 PM schrieb Boqun Feng: >>>>> Hi Jonas, >>>>> >>>>> Of >>>>> course, if we are really worried about compilers being too "smart" >>>> >>>> Ah, I see you know me better and better... >>>> >>>>> we can always do the comparison in asm code, then compilers don't know >>>>> anything of the equality between 'ptr' and 'head - head_offset'. >>>> Yes, but then a simple compiler barrier between the comparison and returning >>>> ptr would also do the trick, right? And maybe easier on the eyes. >>>> >>> >>> The thing about putting a compiler barrier is that it will prevent all >>> compiler reorderings, and some of the reordering may contribute to >>> better codegen. (I know in this case, we have a smp_mb(), but still >>> compilers can move unrelated code upto the second load for optimization >>> purpose). Asm comparison is cheaper in this way. But TBH, compilers >>> should provide a way to compare pointer values without using the result >>> for pointer equality proof, if "convert to unsigned long" doesn't work, >>> some other ways should work. >>> >> >> Based on Documentation/RCU/rcu_dereference.rst : >> >> - Be very careful about comparing pointers obtained from >> rcu_dereference() against non-NULL values. As Linus Torvalds >> explained, if the two pointers are equal, the compiler could >> substitute the pointer you are comparing against for the pointer >> obtained from rcu_dereference(). For example:: >> >> p = rcu_dereference(gp); >> if (p == &default_struct) >> do_default(p->a); >> >> Because the compiler now knows that the value of "p" is exactly >> the address of the variable "default_struct", it is free to >> transform this code into the following:: >> >> p = rcu_dereference(gp); >> if (p == &default_struct) >> do_default(default_struct.a); >> >> On ARM and Power hardware, the load from "default_struct.a" >> can now be speculated, such that it might happen before the >> rcu_dereference(). This could result in bugs due to misordering. >> >> So I am not only concerned about compiler proofs here, as it appears >> that the speculation done by the CPU can also cause issues on some >> architectures. >> > > Note that the issue is caused by compiler replacing one pointer with > the other, CPU speculation won't cause the issue solely, because all > architectures Linux supports honor address dependencies (except for > Alpha, but on Alpha, READ_ONCE() has a smp_mb() after the load). That > is: if the compiler generates code as the code is written, there should > be no problem. I am starting to wonder if it would not be more robust to just bite the bullet and add the inline asm helpers to do the pointer comparison outside of the compiler knowledge for each architecture. This should work fine in the short term, until compilers eventually give us a "compare pointers without allowing the compiler to infer anything about pointer equality". Like so: #include #define __str_1(x) #x #define __str(x) __str_1(x) /* x86-64 */ #define bne_ptr(_a, _b, _label) \ asm goto ( \ "cmpq %[a], %[b]\n\t" \ "jne %l[" __str(_label) "]\n\t" \ : : [a] "r" (_a), [b] "r" (_b) \ : : _label) int x; int v[2]; int main(void) { bne_ptr(v, v + 1, label_same); x = 1; label_same: printf("%d\n", x); return 0; } > > Regards, > Boqun > >> Thanks, >> >> Mathieu >> >>> Regards, >>> Boqun >>> >>>> >>>> Have fun, >>>> jonas >>>> >> >> -- >> Mathieu Desnoyers >> EfficiOS Inc. >> https://www.efficios.com >> -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com