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 E0A8ECF6497 for ; Mon, 30 Sep 2024 09:15:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 295876B0113; Mon, 30 Sep 2024 05:15:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 243EB80020; Mon, 30 Sep 2024 05:15:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E55E80017; Mon, 30 Sep 2024 05:15:37 -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 E3C6C6B0113 for ; Mon, 30 Sep 2024 05:15:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 61254121C1F for ; Mon, 30 Sep 2024 09:15:36 +0000 (UTC) X-FDA: 82620846672.03.CEFE3F7 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 6DA0620008 for ; Mon, 30 Sep 2024 09:15:33 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QgSvdhDw; spf=pass (imf03.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727687670; 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=R504Vt0ci9sSs5hDFIgMgmgRSMuxflw8Qv5wpi5Jf4U=; b=W6KQSl8veGtTi8VyRhe+FhtHp5eN5I5WYtd72DG/EjMota/aGM0N/JAT40JbvFCX42msZb uGaNDsiEJU7HkWHMW46CTRRnLZkPqH7Sn+sKrje4SwR1/WIxtLWrRMFjyBgRDOFHjMu1hz 9/eU2bBy20c2y+f/bx/5P1lb5dRrdpc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QgSvdhDw; spf=pass (imf03.hostedemail.com: domain of mmpgouride@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=mmpgouride@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727687670; a=rsa-sha256; cv=none; b=AwQZX1PAjcmR/mNAsMfmI0fXBNU5roP8VnuCBXIdRcGN9FqP7vyp2Yz/h84QZSGXSeNcoQ 7Z+bJR6kFjJIgDqbND4MQ/73QXe/Gznacg3L6txtvq7iqSqQdjqOyooqT0wF46Fi3XSQsB b4q7+QOBOB69svq53TQJr7D/MPE1gg0= Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-656d8b346d2so2473750a12.2 for ; Mon, 30 Sep 2024 02:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727687732; x=1728292532; 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=R504Vt0ci9sSs5hDFIgMgmgRSMuxflw8Qv5wpi5Jf4U=; b=QgSvdhDw9z6PNl0gXirOff6G888EQRLdUZ8/x8Yh6ySA3S2jt8RhR7GkxxMPHCGC1b eGF++1hGDHFGdZoBhgtw8xSPXL7nRwXaj7ZJvxX0/zxLlIyYYABN/F7D/i2KuDXWd9yO 7afjGXFasjCu3Dkdk9LSXdZb1hmNkF5Q4ZU5NoegxoEHhVZPKTpJJQtRkkPMkld+ByET VCaYzoOFNff2kgxDMLL8+VdO6NALtTdxhlsytSmbpzycl2Ph42AOLdovVwZbk6BM1sXO ZqkDxedopwazAsjsRugzAIIyECvEhHSN4n+tImVMipRzXC6j9tmgErL1GDeSYPsyLBE4 9SZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727687732; x=1728292532; 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=R504Vt0ci9sSs5hDFIgMgmgRSMuxflw8Qv5wpi5Jf4U=; b=QSubXjF+MasM0h/DxPxHqRc2sK8SCXvvA5rZFdUVzl/A98RRQzOtNMbbehcmX9iAbB HudfAv9pas2XYN+3ImX8zuYYiSqW6GHOgok8+phKUFNO/ydHjHWn2L3MXoNujMSK6iIS WmRyPlXe1LapjWCI2AMquOOs9P2Vef8I5FBxMCSDgdONKwNTLTo6qetMn2HSQczBWzdd 1QIS5dbFNrl/uUPsmcf9a0Uwf6hFo1SAJrV2xssO77d4XXJzwmP6bBB8ImEqtYHhlTYH C1qAeM4Bl+DveqeKNlN6Jq2hF491QjKke05zE7+U4YxjAMpCILVYSfeMcz5f4xU3CWWz ELkQ== X-Forwarded-Encrypted: i=1; AJvYcCWYYi4cZUiRiVD2JAUCIKAxBhk+fiEySxP3QjzHmn0J8hJGLz0xkY2B/n01FOqWhIbSeLeR1ik02A==@kvack.org X-Gm-Message-State: AOJu0Ywq+QYZFxJ0Vw7hlIRIvu/bd+oBBCCVN8LfJDnXAkfLa4fWyeAw 1L5/ROo3IwtW3F1eey1Rsqer3Zh7/AZ/5CBxA+w5KyHg4XQGMwFp X-Google-Smtp-Source: AGHT+IEye/2jxywunUzGiWYx+lzoY43g0ARL44Gt8Lgn3tnjajGuJZFxsxmzrRLv9R5VuNJiNRPfrg== X-Received: by 2002:a05:6a20:c704:b0:1cf:2988:c34c with SMTP id adf61e73a8af0-1d4fa6c77ecmr16362116637.22.1727687731944; Mon, 30 Sep 2024 02:15:31 -0700 (PDT) Received: from smtpclient.apple ([2402:d0c0:11:86::1]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71b264d7286sm5962229b3a.93.2024.09.30.02.15.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Sep 2024 02:15:31 -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: <8d20cf79-9fa5-4ced-aa91-232ccd545b59@huaweicloud.com> Date: Mon, 30 Sep 2024 17:15:19 +0800 Cc: Mathieu Desnoyers , 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 , 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> <8d20cf79-9fa5-4ced-aa91-232ccd545b59@huaweicloud.com> To: Jonas Oberhauser X-Mailer: Apple Mail (2.3776.700.51) X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 6DA0620008 X-Stat-Signature: ht7h4fngm15qkdajm5aowum8qs1oyof1 X-HE-Tag: 1727687733-639987 X-HE-Meta: U2FsdGVkX1+LT+8vde7OlBFpTW/Tujwhm6Ia99tDJJlmvobaMaiPoH1l/DeeQVKa/UyM3BN6RcoKoqLVg/ywc/raumy1/zBQIvTrLID/o5s/B9yL+3Ly8sO0oHODrHc11BXvEPeHGPj6CW5iCunDqce7ZPBLeNETCbRcPoICO4cbirxyyzoM1tiZZ2RaPxDWFtyykIYr8MwulM7MFBoBqzV0pP4b67nq9TkvdjxRbhGj763VgyBHI7X6SzsLkP6oqhvSiuXxDnv69c1m4H3UMhw0xAmb7DMSj/npUdTzraDYx4GbRbFPKtSsFLRM5GxNTUFtfY896KheUbdejX4eJPTiPsoiHPb6kLx0tv9cyMit+OecNZ+K4iZ4oo6E7ute76xLIgn69sh5YVK+8mxOvjzCEzTih5CuMwG9PXJftEG6LXddtq4c3N9ltJB7Q+HlWkXt8GDnRrl5a8ZzeeZ25KYlPKMo9QY/cXWonivf5m0mGbChgOhTN1HEm/p+K3iiH4KWn85qje6prY9PerDF3tJpxmiTrzsBZnzlYzwh54o6VSE2/rWgTicFDkM189faGZglbH7ynSj4BGfBEwWOPXi90607mQ/N2qy6f3GDQgCw8GouE/1WBCfZwxBECoqc5QIjDbYk0IyxzRHGhxKaopl/1WEzkuBuhUUg9VyoUO/E7p/aILzxn8lhbM6wp1joBcqlHvJsx8GjUU1D+ZsK3Qn+QirMsPtX5lMKNukOR4DENVZvpEhw2EbiA2cfwiYveFAPVzRMx9m1ptKmgjMqcr/f+mHpJEIQqWM5w00MOFVD1LLt5F4ElhmX4gBCSkz3X0+DA9zWD0QYGDDvfrZ2Xd2/Clg6ctX1gvMXEfpZmrd/YdSbZewTlvnNK7jV5CFJ+5k2IW8w6VsqQztk9hcK58JZvAfVTLkMFhI+3+kU5iLsr36WHRoSxiRDjkdRX2Z3bQWjjxPZsjvFNAP8nUn A8Nvc/xK GJmbpx5AYQBeI3o80+ZJ8eUjOo4YR9jeef2tfyHvKrZOAYncw6yKeFU2xQFjSjB/yARnEXLk1DIudaont4DTm4Yv8k2f59HLnYPVGSpYbxBz/EZmcx387P9Nzi80ztIrLN+CxxFCMl5mCS4WZAS4OASeEMpJRLiAShZYOZdlSYFgD6nYxte9P+PFQwR6w6KpboqLdBsmuaP8/ALZoBH8k74/ocFnS4kwU+BBaREonx1kJJCtuBmaiNnHq1cmZD/4u0u7XXD1wraWc9In6gptU7W/uGPSNXlD/qCfHD6phmBGjqXBj3Smo/EdPOYwRTTiWRckf26svgy1POj9rxW8KtRpB5FPG/Br/1aMptbapclplovL9m+78C5BjGOpZMi3WZKyZ3Mg1aD3Vl32nk1YV4AVW6PnhjTVSIM7oe6y78VMvf5ZIo3+RTxtRITKp8uJxsCp1uuWXskKuwROfEWeFPJwp01c4x17vyTHMa12XTNULvxXq0vpP2SzcSLm0iHjrQRogXFA4aGEh5qwsKEvoSt68kFbdnEboTxuOTwu4N4OG5WzyNihuWHxwsWTqaNgwVO6Zkt6dQO2wpz+4ya1CVECAAkp+kNiIzZ/7lkkWYqvNx2muysjYncBuekOOXbRx5dXHDAhcUuRUGadKb5zwd/NVfbATjDc14f89 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=8830=E6=97=A5 16:57=EF=BC=8CJonas Oberhauser = =E5=86=99=E9=81=93=EF=BC=9A >=20 >=20 >=20 > Am 9/29/2024 um 12:26 AM schrieb Alan Huang: >> 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 > I don't think one barrier_data can garantuee preventing this, because = right after doing the comparison, the compiler still could do b=3Da. >=20 > In that case you would be guaranteed to use the value in b, but that = value is not the value loaded into b originally but rather the value = loaded into a, and hence your address dependency goes to the wrong load = still. After barrier_data(&b), *b will be loaded from memory, you mean even if = *b is loaded from memory, the address dependency goes to the wrong load = still? >=20 > However, doing >=20 > barrier_data(&b); > if (a =3D=3D b) { > barrier(); > foo(*b); > } >=20 > might maybe prevent it, because after the address of b is escaped, the = compiler might no longer be allowed to just do b=3Da;, but I'm not sure = if that is completely correct, since the compiler knows b=3D=3Da and no = other thread can be concurrently modifying a or b. Therefore, given that = the compiler knows the hardware, it might know that assigning b=3Da = would not cause any race-related issues even if another thread was = reading b concurrently. >=20 > Finally, it may be only a combination of barrier_data and making b = volatile could be guaranteed to solve the issue, but the code will be = very obscure compared to using ptr_eq. >=20 > jonas