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 66EDBCF6491 for ; Sat, 28 Sep 2024 15:57:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C075B6B024C; Sat, 28 Sep 2024 11:57:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB6836B024D; Sat, 28 Sep 2024 11:57:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA5196B024E; Sat, 28 Sep 2024 11:57:28 -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 8CF3E6B024C for ; Sat, 28 Sep 2024 11:57:28 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0EC45120E65 for ; Sat, 28 Sep 2024 15:57:28 +0000 (UTC) X-FDA: 82614601776.19.812B0AD Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf21.hostedemail.com (Postfix) with ESMTP id 5F4011C0002 for ; Sat, 28 Sep 2024 15:57:26 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=FvoaUoVC; spf=pass (imf21.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=1727538923; 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=Gbqwny10hH2rVcNfL3XoPH+0Zv+L4KW7yu1/J3zd4po=; b=q//pCxgc95rOuR8pMnC33Lom/x1Ky19JRiy7cXsLe6BzrUwS9R9mXoE/D/LL9xGIWDSbIu W1VuxFPqYv+rDY0vMGn3ERCuWQ1cvr42PfLfBOOIOVZyv8sJrtOf94wHuhxlL+FGod6exO ALFDdwdjj5t7MpS8DSGCPLjmyCrLkwI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727538923; a=rsa-sha256; cv=none; b=NQ9YJjV6CWv7kTg8kJyszwjWkfOT8rcQH7ZzoHjUax64/2MEbV8yleVyYv7bQV3FdIiPon MN/8CUWcSdmu4JFawrWyM2ctZowQE4IxqO9UUqLtm/AtYEL7kOJS1JirW3m/hoefw3wQCZ 8fxt0lwXPqvd3G89IkYuj5w80/i3hnI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=FvoaUoVC; spf=pass (imf21.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=1727539045; bh=OT5+a5qZ1o8omlaCZ7kGSp45uaSP88DQUWgurlZRS/4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=FvoaUoVCkk1vlFwGKRn1BPSxesgO2ojACv9ZacAleSmS6TGVCqaZ/OfDlT1chVCAS HDGh65+0A0LCmXPkguJXDQXtB9Cos7jWdqq/QE1HYCVHOqYrJerKBsQzC+JKphGByf 82dhG6UawKRMs+Xitf2UKZGQEn676aHJuo87ix9Edj2EVTTQD38F4VnqH86NF9/2mG 2Ff8V3pD9kpPIFI6MG/yytZ75PH/ZPCLXProkF32hqn+XNuSbAk37I+vwypQ7z+IUz ljxDZ9Efm3tCoGa2fuLhiPLt3S70NJM3TZUjosE1XilIFYcs0rlw3StbWdIb2MVC6k XFx3z5WbkG/Aw== Received: from [IPV6:2606:6d00:100:4000:cacb:9855:de1f:ded2] (unknown [IPv6:2606:6d00:100:4000:cacb:9855:de1f:ded2]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4XGBmj27MNz1ccf; Sat, 28 Sep 2024 11:57:25 -0400 (EDT) Message-ID: Date: Sat, 28 Sep 2024 11:55:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency To: Alan Stern Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sebastian Andrzej Siewior , "Paul E. McKenney" , Will Deacon , Peter Zijlstra , Boqun Feng , John Stultz , Neeraj Upadhyay , 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 , Gary Guo , Jonas Oberhauser , rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev References: <20240928135128.991110-1-mathieu.desnoyers@efficios.com> <20240928135128.991110-2-mathieu.desnoyers@efficios.com> <02c63e79-ec8c-4d6a-9fcf-75f0e67ea242@rowland.harvard.edu> <2091628c-2d96-4492-99d9-0f6a61b08d1d@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-Rspamd-Queue-Id: 5F4011C0002 X-Stat-Signature: 98zettfs4ow363etza9sddbkrejsinpq X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727539046-44141 X-HE-Meta: U2FsdGVkX1+VMVzklkGiS4isudaX51Hz6jajOxg+owOhFgqCOYuEZzkSeB0I6/4bAt/REj/2Z2C/pIkpF95kP1C3rt9ZxdO+f+ZKCH6PzGmabRvZX9+2lK/hG/ceYmAAgEY8yTKkY870oKyLtI3v4SVdiVjiW+e5MenJRuKLbOcFswqm1XGi4DhQrE1pLM9x/MnuAPcbVzOkDdtOx8zJB8/RmfL/Uq2YHoyS/+N+1oBc1tjatudwGm9Dg9ugVGQXbJ2i911/9DGQ+H/nrwrSr2+eSPhu5WvtIcJ5qaAR87gvVC7qKk5on8v5okpZLLPMLnXJD59xI++obc8ljvpfTH46bP1QcaflbDzNtBqHuSCbkSk9SwkyZFR1l6ot5TMo+9o4Am3EQWC72xM9k4LoFNoZuMIgj22AlRlHczRQFfE9o+41PssUgYd5eJc6DDU0GMyKeAs5xj1z9E0GXW/9NDiCW9s+6ctxcdK9x+SJpJgJh3JmliZdyY5UxBuUUeAKS+JQMg+tb2cDAIOPGJPRAkAVWvba7JWft95x7hNs0SzZ9stqSe5H6Mvgx0mgfod2oNK7D1AbCMrLSu/LwLU4MQiT5KhKOW35VxZNZ5CRg0Qcn08ELdgx+5CJCNfZcNNfGwQ3lOcPtlY6EZdMbriDvTTnVUUtGpleoG5sJ6s6i6waklPwPrL5lnNxBHwfPlCvwQfFf+QiSoIYrBk8vGp9LqJ+5tIvVAmrve/Sv9+B85HnLIp8FMNmAktp6yLfxJSi0igTB668k7XFTo9McBmKnbsLE5MooSmxcv7KvauwlWPQP03mjvff8qFmTZ6ophBrM0/emA54sZee7uUiD1Ms9PcLvfBkvIy1avCzGC1xH/lIWZB4ZfXVSuqgTlt0MgJEh7Rh0vAr4KJNrI3WNwTGy1pQednG3hSh9vZcADlAvXh2EOGs+qCqlQyhELBkdkV6rcdub0n4xZBUe08z+Iq WZcz4qwr 01Xfluia37gcFB++OoBTnZVT79PUdw/Sdf9vO+FceJ4KSYvfsUX97B/eqcB/B5WFC1ZJQ5HjxcLFRIIHXCP8ljj6AxD0DVpwAsDEamTaW1IqxxvfR6upshC9biDBHxylW41NXz6xGaKVJ+bm8MtAfL32k3HpqWFGofALomUOK62DJj4upfJF76owQ3PJUrm5uxPxdvaXlu2Z9Nxaax31Ugt82tuJRvUzgMFqZjbmvUPttReY8/HYVj/V8pZExg0GEdAMFtNI6uaeqGU2bm+xQtvY6pXmXdzEiZeuNhb7tzlWjHz/iVIjDeXTSgaG4dauSB/GRCxfN8ytx3ONhm6F0uzdX3Gdc56saSZNV8pnBntBfmgx2g6nfJ745stAB9z9brNkujRSKSkHK3zYhDV43ly9bSqLZHfhWNPC+t3AyUCojeHT6UjsP8vWz8aXyN9DlcT1q6XV7aT1xnw6A+JfyHvOjTJko3d9bJbChuLSAvEzs1rs4CX3UBPWKmA== 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-28 17:49, Alan Stern wrote: > On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote: >> On 2024-09-28 16:49, Alan Stern wrote: >>> On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote: >>>> equality, which does not preserve address dependencies and allows the >>>> following misordering speculations: >>>> >>>> - If @b is a constant, the compiler can issue the loads which depend >>>> on @a before loading @a. >>>> - If @b is a register populated by a prior load, weakly-ordered >>>> CPUs can speculate loads which depend on @a before loading @a. >>> >>> It shouldn't matter whether @a and @b are constants, registers, or >>> anything else. All that matters is that the compiler uses the wrong >>> one, which allows weakly ordered CPUs to speculate loads you wouldn't >>> expect it to, based on the source code alone. >> >> I only partially agree here. >> >> On weakly-ordered architectures, indeed we don't care whether the >> issue is caused by the compiler reordering the code (constant) >> or the CPU speculating the load (registers). >> >> However, on strongly-ordered architectures, AFAIU, only the constant >> case is problematic (compiler reordering the dependent load), because > > I thought you were trying to prevent the compiler from using one pointer > instead of the other, not trying to prevent it from reordering anything. > Isn't this the point the documentation wants to get across when it says > that comparing pointers can be dangerous? The motivation for introducing ptr_eq() is indeed because the compiler barrier is not sufficient to prevent the compiler from using one pointer instead of the other. But it turns out that ptr_eq() is also a good tool to prevent the compiler from reordering loads in case where the comparison is done against a constant. > >> CPU speculating the loads across the control dependency is not an >> issue. >> >> So am I tempted to keep examples that clearly state whether >> the issue is caused by compiler reordering instructions, or by >> CPU speculation. > > Isn't it true that on strongly ordered CPUs, a compiler barrier is > sufficient to prevent the rcu_dereference() problem? So the whole idea > behind ptr_eq() is that it prevents the problem on all CPUs. Correct. But given that we have ptr_eq(), it's good to show how it equally prevents the compiler from reordering address-dependent loads (comparison with constant) *and* prevents the compiler from using one pointer rather than the other (comparison between two non-constant pointers) which affects speculation on weakly-ordered CPUs. > You can make your examples as specific as you like, but the fact remains > that ptr_eq() is meant to prevent situations where both: > > The compiler uses the wrong pointer for a load, and > > The CPU performs the load earlier than you want. > > If either one of those doesn't hold then the problem won't arise. Correct. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com