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 909DCCF6496 for ; Sat, 28 Sep 2024 21:15:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1871C6B00C9; Sat, 28 Sep 2024 17:15:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EB696B00E1; Sat, 28 Sep 2024 17:15:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7E886B00CC; Sat, 28 Sep 2024 17:15:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BFD7F8D0001 for ; Sat, 28 Sep 2024 17:15:37 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3403714159A for ; Sat, 28 Sep 2024 21:15:37 +0000 (UTC) X-FDA: 82615403514.29.A00B837 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf30.hostedemail.com (Postfix) with ESMTP id 3CDA88000B for ; Sat, 28 Sep 2024 21:15:35 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=rowland.harvard.edu header.s=google header.b=RxguGUfu; dmarc=pass (policy=none) header.from=rowland.harvard.edu; spf=pass (imf30.hostedemail.com: domain of stern@g.harvard.edu designates 209.85.222.169 as permitted sender) smtp.mailfrom=stern@g.harvard.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727558034; a=rsa-sha256; cv=none; b=mACtWEJtJaxabDLOlzod9/+c8/googG7d+cDjHmATbpdkEJEgoMMgCZhHocYrkH3xB6sCd JXbzWiKF76mjBaxfGOSIWGAKujbAq6hx/hEMNd99K7pAyLuokSyRA7B1pTonyd5pVoQb3N JH7S+6+JnACVgFn6XU8M47FZy7AesBg= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=rowland.harvard.edu header.s=google header.b=RxguGUfu; dmarc=pass (policy=none) header.from=rowland.harvard.edu; spf=pass (imf30.hostedemail.com: domain of stern@g.harvard.edu designates 209.85.222.169 as permitted sender) smtp.mailfrom=stern@g.harvard.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727558034; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9PxKTMIF6DeQ/9qr6txQjiAXMf3+GilsmbRaxHtQjSE=; b=weCOCPvUjRzhe7PXF6q+9K7qyzGxD4luTnJC+aKR7Sd2mRpAvRRikyBJD048fSYll8WfA3 qG6dAKp/SpcvElPfGXhJjAvPfglE5FM9Bn6DpjGaUKOJHWAilSpV2EpYNdcEr/gbK7yW3N VJC5/yaE1lJdn4c4+6asxnjo86VVw0k= Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-7a9a3e731f9so288117585a.0 for ; Sat, 28 Sep 2024 14:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1727558134; x=1728162934; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9PxKTMIF6DeQ/9qr6txQjiAXMf3+GilsmbRaxHtQjSE=; b=RxguGUfu/d3E7t4SAqo5uSVsvJ86i5micht8iYsm2t8+2qbn5v5a6nMzsH4Z8RdbE5 vJNEZB3O6CkTAPGHB1C0KlhlSR8d3YiyI5GS7IpXjjmNTYrzQcuwo/TXP/6qVOQQeS/2 lsQDniebFMSMeuvq1FReIKC60kFXyOArkkVkSdWJMThXYEv1HQfwqJjRyRxTop8evu4C KGtTwSu/JbyGek9UNG5n1pKYb8tW/RcZ+nXNUC4k6Afi/t342+8Oe79d58XSt4YlftPy l5qhqsWUcbWXc4PipaHleShY6wtzrDdoBV9dXa3qmuIrofJVwX3ETtze4CQlbrpGFY+a Hrow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727558134; x=1728162934; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9PxKTMIF6DeQ/9qr6txQjiAXMf3+GilsmbRaxHtQjSE=; b=Ekfb3qHgPOkN3YLzyYbizSlIRHSpWsg5oYGVXRuFcSechCRdeHnDWYl3eNg5lforVd WpwuPDRDjxF+TS9qMW6YmCx4dRzejJ9XKnNc5EbUWeBv8RRbwP88HUWgN0MDG1D6TKXL guqgyn1j61klwJIXfC3TA7ozSgNF9UaPw6CFYPPdyBy+nb1bIAWi2b0ph+CDkUkZz4NK drUNkFWlz/6SdaAbBrTMGBlI438lN8HrhzaqGI3idFIHllZ0uTWKTinuhsTYfie+y9dN c1EYXsf84cuZlGBo+Naf3N6uWcqNUbJmLpkiWSiwAFerJAy5xFacsltrkRzwKD+3Isok XEpg== X-Forwarded-Encrypted: i=1; AJvYcCVNqNq3uW/ezymq049oXIdkuhU0ncgaIM+cAD111FGWVGlR42LupbELk3kcJ89/G8KHi9olBvG7xg==@kvack.org X-Gm-Message-State: AOJu0YyDCZq1rM173fpR5ZkHKgJMO5zFd7IlzTpUe30JLdu2nI1W9g0Q S0UXhmWBA7jtAsk4djjEGBPZbx2uYllWAySBIzAuVII7eO03U7mxyhqAAQLggw== X-Google-Smtp-Source: AGHT+IE6VdKHTwplHgwI7PZXwbNIB2hr26lmUE6zQ4ZThO/awD81T++nWTivo6Q1AxoadzUpc2/TaA== X-Received: by 2002:a05:620a:4707:b0:79f:12fb:ed1 with SMTP id af79cd13be357-7ae378380d2mr1176831785a.16.1727558134233; Sat, 28 Sep 2024 14:15:34 -0700 (PDT) Received: from rowland.harvard.edu ([2601:19b:681:fd10::abbf]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7ae3782c745sm237384485a.90.2024.09.28.14.15.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Sep 2024 14:15:33 -0700 (PDT) Date: Sat, 28 Sep 2024 17:15:27 -0400 From: Alan Stern To: Mathieu Desnoyers 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 Subject: Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency Message-ID: <25344f33-b8dc-43fb-a394-529eff03d979@rowland.harvard.edu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3CDA88000B X-Stat-Signature: gfgrbtc7ezebqbqnzss7f1crfdkx5uac X-Rspam-User: X-HE-Tag: 1727558135-329191 X-HE-Meta: U2FsdGVkX1+89ZyQ4c6wtiPboZ1IqcJXFQ/CbEgumEycSYK98Ud8e7O+UxpVi76kgoduc8g3uC0+qLj03LMaM78LnH640dsEwqPyJuoEJ1dJ9xHWn9Im27FizGQb5mA8aSEUGmTFu5W2LVPzYSJb/TZ1AZombp7h+CcaGuO4z6/ufn/rNS5Zuvg1AyTTIO4JnhEz938WBMv/rK2RitYwazDusTteoWUJ3cX5M1vV270HhZYsbN1BdDVxQZ8AM9UxUIYiNZFr0pQnXj5ZhkRPz9Y3KB0sCxzBmNrfvKmLTC6OiC2K5sR1EI6l1le+uTuieDmjnOUluTNyYCJcJ+rt65UEYrYSbxiWMsZdYjCCDDrNesy8fbJNZBL0sLqR9LVgwhkGngp6bcTVMGRTYnRvNMEMgeD825vqWL+AEBMrMZ2i8YxPst90bAjkVn1HrkAA5EdEviXjsgpP6UEMUCUaj/mC9LS73WYy+QaTrrm0a/pz0CEx3IqwYkdaUFMfkN8yWa3AuqTeP1MJ/FAmsaDK4YUE54OttfLWud8e35lm/dI1NgeaqsbiYAKUZN45EezQV2vR1blTNh6aXEb0t54GOJ9llLw6k8FaQ1seWxNZ30JFsxbLnzrczjfPLYfBJXFNXnBPyjxsmNKOXtp9T/QBufut6fh7p/isr2FktYsZujCSqd8OHCQ0/23d9NzdMxP9/CCylhVX25glmTSkGw81uRrdf6IQA86IBx4mvZ53kmp0K+cC+8qv4NcsbDa7wcNJ24nl6ju3+DVfLSArC6uzkhrZsujfzbrfDD4KNzSOb9YcL2haXn7HCuK9qh1rK0i736b923mMzoqZzD2B2HnxBR7HStoa1oiwo3YcxJqE0hWN2WTTJFgFgY9asQqi2r0mHiZD0NT7jOH9ePLBFLKfrbqk3MkxqOCJucuNYkZ0zyU9duVpHFH7+MxV2IKs+RCf0q5VfQnPxJDW/G85iC/ zfSJg6l9 zc+WbFh2DEjkuMfPRyGHM6vnyUmpaxN5f75lv0snffCOCAIyVzYhziO4RCByIp9gjPjnp0qsEavkoR1iX3lJmdS0z3ywsBDN1mT/bkBSGfOcXNtCykcRmWi5BrDBZTAutAz7SRrPN1+NPxkb1keTKG/VMsP5Yc+RxYaJg1/06+wF/f4gRffU8OYM30/Ku5JZM3Ez0n1jr21NMKwHhIxp4ZaDLWyJ5QAv+rxTeJegtUQ1UyKq81F9GVzQ0B5INygekfY93an7uuIsgN2Sl/0kyQecaEO2++2KV3ID/bHLETbKaswyVcGYPuwqmTaqr2/3RkjJU4KHo/SstHYdCDueLL4eWYS2BXuVAcvcDaYG8UjCaQWGT0HPhxNz9Hkltyy+LHI2OGRtZe72b6cBL3RTHQkMKFXnxf9PExLMNt228m7XOkQEEn19JjKe2Xlj5Ew4xwiSsQHFSZ09juNeqt8cUXaQSgwtY17mcG2UvyqXuraSX/8rLYamx5mXJEi+U2Y3tbXZZNcoAonSDTBiYnLvw9/UIvtYYMDf+9VZDpg3gnuygzFsWCRVi2c+lBhHOdSIKTNL9BeQUNJAezccxxy+KKeZMpQYxwK2MyMbd7n99UNCVeWOM6hFYYoAR64r2W/ibyELlEaM4zBDkNuEVnRmKBPouo+r5woaeCOPF 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 Sat, Sep 28, 2024 at 11:55:22AM -0400, Mathieu Desnoyers wrote: > 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. Isn't that the same thing? A constant pointer like &x is still a pointer. What you want to do is compare p with &x without allowing the compiler to then replace *p with *&x (or just x). > > 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. I don't see how these two things differ from each other. In the comparison-with-a-constant case, how is the compiler reordering anything? Isn't it just using the constant address rather than the loaded pointer and thereby breaking the address dependency? Alan stern