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 ACC51CF6491 for ; Sat, 28 Sep 2024 22:27:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6C256B00B7; Sat, 28 Sep 2024 18:27:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A19966B00BD; Sat, 28 Sep 2024 18:27:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 892356B00EE; Sat, 28 Sep 2024 18:27:08 -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 677176B00B7 for ; Sat, 28 Sep 2024 18:27:08 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E8AD91C7571 for ; Sat, 28 Sep 2024 22:27:07 +0000 (UTC) X-FDA: 82615583694.29.C9C1277 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf11.hostedemail.com (Postfix) with ESMTP id 1863440007 for ; Sat, 28 Sep 2024 22:27:05 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YkXh+9SM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727562334; a=rsa-sha256; cv=none; b=SrNHnD+Rdy9w8Z00vJVa6ipUQcTDC5Ie83c9+un27rlKgyELKSvozDveBp4OTjenPEYg9h GqR2yepga9/GrfJxnLGa78gK0VEmMPeo9ZGrK6jmHI8Ayfh3HqmC1+elHqXuTR7U2gdg6b tS0MAmk13U7hQid6ieAlS3oG3sgktqM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YkXh+9SM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727562334; 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=39TwabcFKO8PAh5Fmj4zbLOsgDGHvVg85M19XMWn6GI=; b=3qyVidM6qUz0OrTrdnoAf/kWxnGupJPWNSWr0LxnoIV2BKp6GvKyOD2B9a9MCnz8d8eWdO YSJKtQSsUT6PAWe11H4f+DWAXtZ7PPsf6kVGkCNeLZmDy7wHEgHmw7XrpuXgndTAiFZaKt RW62JigMLQvHQijVMZG01G9RqLRyMBY= Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-7db0fb03df5so2480871a12.3 for ; Sat, 28 Sep 2024 15:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727562425; x=1728167225; darn=kvack.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=39TwabcFKO8PAh5Fmj4zbLOsgDGHvVg85M19XMWn6GI=; b=YkXh+9SMyhF5iSBGnnpAWQYKhgnxSDjIyqBTxyY/p/qpzY68r4oobG19Zz7jQ5sOMF j4T5jvLzyfPYV5mRRuzs/kAuncvJI2nummbFMs+2jbZ0AhbAFuiYfapUZQ3/+sXSEd5I TbdFk3Mb8pgH5fufHkmQiQIoBIJMorVHePpLNMOsFDYKokBf+8InD68VF7NGxDSPWSUi LNaLIMH0wKa9NbY7YhOkkjObs0JxmzrTNAp6ztK3B3eG2qmLwbvv9RPun6dXHbS/OGDJ 2rTv7uOqJr2/m1/c3Um7+32m1Aid+SojHZZIskE6mINta5Xr/nOLH0RrUSmuMSbdAq1r sXOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727562425; x=1728167225; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=39TwabcFKO8PAh5Fmj4zbLOsgDGHvVg85M19XMWn6GI=; b=nPIEMqwBJpb1UYhNqQd9zSNMQ5pHi9UhXgWjlxB4mx6uBCzIG8KS+YDZvNVIyBiuM0 8VcKfmqkYcmweBxELuOY+JrfORQs3Uin+ru/IW9bGL0+OXa2uEk53ZLa79BIBG2sTTrQ pIDvmKlI73eubwmLFEkQVZK327OUFrnFQdUDfl9+y+c0WQv9imJ8YwszYSIMZXTb6TpQ wvPS97VTjr7VPwGI4gz9ADJ4qDxON1JfqOKoMY4S5mMPY5o9ohKMNbpmyTUio9TYlDUN JcOD3cn5iqsGrllZU2KIY5H8QXOlD7DudUQftkE0E+kch1SHjL95sMxLqOQs5mpfhWNH ltrA== X-Forwarded-Encrypted: i=1; AJvYcCV8RuYHaLlsY1MVWWieoXDdBd/Cf0ZQTQyd5dxtHfOeMcu/eU2en8ybQVV32d2WYqPLZJ5S3m5XIw==@kvack.org X-Gm-Message-State: AOJu0YzR60oWzHRwoo4/vUg+gnpy9B4cScX241suahkBqdEueUU55lfi 5LUDcMpUhdxQL5QPRc5wKAA0w7RmsdPfawZ5dfng5BRJTOO2LZn6 X-Google-Smtp-Source: AGHT+IHU++ItzZuI4JRlnnSPKUEq6zSjBveX5lFZ0ZRGbjdCCFJ3yEqulKfbG3mepSJoVqt/Zuzl+A== X-Received: by 2002:a05:6a20:1b18:b0:1d3:ba1:18f4 with SMTP id adf61e73a8af0-1d4fa6c7bd2mr9103220637.26.1727562424750; Sat, 28 Sep 2024 15:27:04 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7e6db2bce30sm3269533a12.38.2024.09.28.15.26.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Sep 2024 15:27:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency From: Alan Huang In-Reply-To: Date: Sun, 29 Sep 2024 06:26:39 +0800 Cc: Alan Stern , Linus Torvalds , LKML , 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 (Sony)" , 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 , linux-mm@kvack.org, lkmm@lists.linux.dev Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Mathieu Desnoyers X-Mailer: Apple Mail (2.3776.700.51) X-Rspamd-Queue-Id: 1863440007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: tkrbhzeydx5jje8najwub53topgbn8im X-HE-Tag: 1727562425-367871 X-HE-Meta: U2FsdGVkX1+PJWUQRBbAdHhcGY4LsOGbLAbpQpz4EskNcqiph61LvcghECUPgU3LgVnBb4swrVI+/6WqAzK/qyKv5ggOw51J4++TFR1B1ExxCiInIG/sA1JfMr56t4volfAHNwv8LLREXFuSCUF8vaXYekvgrfZtnVU6rAuxR2VL+6x5BvKmvuwduhA1sq4mEgU188GJmN9DOC2+/iKZ9dqClsHKRn4rJRVz51ozRIRb8U0XI4ANrZ+GKLGVVc3ZV99n3LWsLQ0zJ5kk1kxTMGmSlEkUzazDPXcl8z4xxVp4wb4ZUgLkNjkJ5aL0ZQBR0xCji3Bk13yKNt+ZjC89DzsICWqUQa17KkM3pKXEmN1hC/8lGqWoi9uY+R/TOWI6YohFwf+M6prX/SXstf9cKbxTMPtgcy640NZQFTweapL+nkoPDLEm2fndjkEr0IrTN/nOnaCX3gyxAziK8G49kaW+VZz/rq0rF5vANVgF358zhU240tcOO9vtO1vagiUwEva80D6+oD1Ys/UfA2A/ZsF/etCIAEr0g2DU6ovbreCW/99JvW23k2y9wHwFr8QzdUa+iRtv6a6Yd+slswaTBQo4ld/HQvo3Hly2nLHfcamw0dlCPWZkj2OrJ5C5YKdaZUrUbnaS/TKVPQglT2PsLnU0eht1uOsuzsxLwtpgDpLp/oveBfVt4tNbcjCJqb9TPO0+VDYgHbrJVY4mvP0HvuaViZBq0KqJaLjzHfiY4rnrshPsf71OEiXvlYzQlzag/Id4eew7tJFUIRVZQ+jvjdj3GP+wjGazShdMvLRHI3aODfUGdr0SZy17Dfy08blZDg1qymFsNb4Z6UrdA/hC/Qz7lv9jTsQyJ0FcpJq851jHewPqOXxLnu/n09lEt3kk8UoAtWKcAx0RF1KNUIaRi0LsXyBp/mKkD/TNIRn09/RrQj1ehwE/BTaHGIC4xYoOGB7bEXZ1m6SuDtFfRy1 Ax1yK+hb C2YjYBoNWhVTpv//gYfkEv16SDRzDS0OFApyTmXCVfVUg5uqwBxbC6WwQGUb9mAMP1rig/ueSculfbaaFcs5jd8eFfs7aiDYAdiV+Y0O+COXS5t8RtF4jw/B+yX/ojU33vFCPa+pvKZV8NJUWpCXlDdA/SLh+ys3KEmhQLTd/Qdyhfg/t4F27aODdO3cxIDj7UP2jZ8JLGNcyjq+8wqLKq0VnW0qtackEEq6P6wcRBbK2JZuojfaKaZpD6jqbVjft4f+Yr/MGwQNClA5ntz0Q5BZ+xEn1OU/hLQon+sjCK8WNKDRVfoNshAVQZ/P1heABf4+2PRNqmhHyLJorHp5Oi8W/bW7FZW4y4km2HEiiK/mUjqKg/q0uv3a2Cd5V5J+kVW9caO33Vkpt6FK2k6fJ3PRN/k0BVdey13Mu9M/d3mydV5ScYiWx7d7fXBGgoRTNgFJjJQwwhBPWMMlh/0ZSh3EqsyaMLOTC2gnCiRnHEbpuBJIDp5tj+R3Vxx2X5N/SG/MDNGr3kKRDQKUJkhLjhQ+iKre/tUdnyPAsT6MqI5pvj9FhTAzz246g96wPqhJbNhyL7I5TA/sLuS2bMhwkEhiVfXXuIa/DZlVLFFT6DFeWYuu8+mXew96bwgDUPWvKOPIEd+Tw9dvulfI= 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: 2024=E5=B9=B49=E6=9C=8828=E6=97=A5 23:55=EF=BC=8CMathieu Desnoyers = wrote=EF=BC=9A >=20 > 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: >>>>>=20 >>>>> - 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. >>>>=20 >>>> 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. >>>=20 >>> I only partially agree here. >>>=20 >>> 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). >>>=20 >>> 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? >=20 > 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. barrier_data(&b) prevents that. >=20 > 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. >=20 >>> CPU speculating the loads across the control dependency is not an >>> issue. >>>=20 >>> 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. >=20 > 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. >=20 >> 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. >=20 > Correct. >=20 > Thanks, >=20 > Mathieu >=20 >=20 > --=20 > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com >=20 >=20