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 AD10FC001DF for ; Fri, 28 Jul 2023 17:36:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAA6C6B0071; Fri, 28 Jul 2023 13:35:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5AF56B0074; Fri, 28 Jul 2023 13:35:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D225E8D0001; Fri, 28 Jul 2023 13:35:59 -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 C365F6B0071 for ; Fri, 28 Jul 2023 13:35:59 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 91F72A100C for ; Fri, 28 Jul 2023 17:35:59 +0000 (UTC) X-FDA: 81061723638.16.AF1F5BC Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf22.hostedemail.com (Postfix) with ESMTP id 6757EC000F for ; Fri, 28 Jul 2023 17:35:57 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=f8BbsCSu; dmarc=none; spf=pass (imf22.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.208.175 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690565757; 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=/t220Hmflj/VPTxFmqAg5Xug/KV6ADyc6uAYVTG6Vgk=; b=FPtsHuv4vScTi931iUHpfHwc8hihydtQB75i8f1YFXgYMumvvBSoiNjUtZ8A6yMhozdodp g0JCD6jdAsuBP7KnmraHU3RAQSF0U2rZ5rqT03Dq5DJW4qQtnREatYj0mAOJvLpGV09D2U Ohhsym7V7Mei0KAqrZrFAYWFi1KUzWM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=f8BbsCSu; dmarc=none; spf=pass (imf22.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.208.175 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690565757; a=rsa-sha256; cv=none; b=uarFUXiCg7YP+G1kTtml4zcPNi1KMNTVGVGpE25QwCSHYFJdMl39JYGhghuzd+xmul9Lkk aSAWCe5UVMmeTZeI57Xntc7QLygfe0KZCEAfsSiRAkYhpWGFNf/Q2l+7Bix6S6FsDQi+ZI zFXWNrDcLuWYnUIFeZqVZq6sREeWwyU= Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-2b9d07a8d84so13232291fa.3 for ; Fri, 28 Jul 2023 10:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1690565755; x=1691170555; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/t220Hmflj/VPTxFmqAg5Xug/KV6ADyc6uAYVTG6Vgk=; b=f8BbsCSuJ+1Vl5ttIizbIBKz3oh9F56xaUVVi0cuYOZXkfp3gq91OmfZRP67EIFml1 Du/E3jw+PZmgXdDBcPxp+29WC9u2XxwcLZ2w8s1ro3NfGTKPSHpvBm/9JpVXcimyA8v3 7HJmYulel6o02OzFOnuga6a1Nhi3ylXxN+VB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690565755; x=1691170555; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/t220Hmflj/VPTxFmqAg5Xug/KV6ADyc6uAYVTG6Vgk=; b=NkgnJd1fMNYbMK1HN8zMFEMKiAW6xRM9VmzXKCnVd1bi7eYHnBUhhPRVh9mxLhyaCj 4mODW367ETP/AyZJoYY1ZY4x3Dt12yct7Y0GkkCO1jw/hhGo3tV6vRcIeTPSvkKvcmGS c5DQ5BBj6m9dX6bvSCWi/pdwEbPNNkYRvj3/mk1ZeKYomANKvzATucxh+38oaAlqXxtv I6GRFMmUs5nEI7j8ecT72Z/8qbppj8UymrvOrHutZpPMNZLAuq3zF+IQedDfCB3RZIeW yaJlwAnyoA4obw1RYFW4SBF9iqm7sLYAAZKdLaCH1GnGOpvx0IR9jInQ+nrsru+TTwMH sMOQ== X-Gm-Message-State: ABy/qLZo8WqOS7Kk07waOmKa1heIIih2tyHflD3lOp4Y0B3zn377ZGYH e3lfojFjVfPOq8UUK3jBOc/F42eJxCT7G+RdF2D8Zg== X-Google-Smtp-Source: APBJJlGeDyQq93qi2ph5y7OaUdlnjpI1araVuyPUyhyGClXnxoOhJ8lj97tWTCK730unzS4pcewYdNRvSpUgA05dIQE= X-Received: by 2002:a2e:98da:0:b0:2b6:9909:79bd with SMTP id s26-20020a2e98da000000b002b6990979bdmr2211202ljj.24.1690565754899; Fri, 28 Jul 2023 10:35:54 -0700 (PDT) MIME-Version: 1.0 References: <20230728124412.GA21303@willie-the-truck> In-Reply-To: <20230728124412.GA21303@willie-the-truck> From: Joel Fernandes Date: Fri, 28 Jul 2023 13:35:43 -0400 Message-ID: Subject: Re: [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering To: Will Deacon Cc: Jann Horn , paulmck@kernel.org, Andrew Morton , Linus Torvalds , Peter Zijlstra , Suren Baghdasaryan , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alan Stern , Andrea Parri , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6757EC000F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: qomjakom6adt3yhmgfie591ko5i74jop X-HE-Tag: 1690565757-265248 X-HE-Meta: U2FsdGVkX1/Qb2vqCJHTc3aAWMavP/z+X4SEgBiLJMZEsW4Wu53xImspwQ3lrO/aU9BXl3P2foLxdB5Mfgk7oE1nhwcMw5r2lq7UBe/FADJhcga9xg7IBT0IrD+LoFYswM/druvU0CMAcPWOGnkigwRv0PUQrS3YFdRwAPcLEYjZPUf7iFlar2SnuIcrhSl5rT0gJN5cuhKBXSvId9yUtGIMDppx5TbVNBw63OFsaVDn1D8ZNKYAvUiHzI/oVUU25oHzTJhaaz935j78ffDJoNcuS5z24m0lc4lcup3gNcv7+YfPu8dsHhSgonhd5iE4fPsk9IC0adNR4kO3edPUL5ZkT+/EBsQo6T4pk3UKQod8jTS+aJtdtf2RMRUMEg4jLuPnb1JrtWvCcRHmMi4Poxlc9Ie4ZYAVlPGHYJdualPGXQ1wwDEAX7hF+WdVOqhbv//Xq2kKNpsug1x8+r9veNNuso7G1jYfBVrnfrrbAhxkPEBtnUdd2L0j7ObUtNWpLAClJupsGmbcm0n/+hSPeypoe1zaieBz3QVWq1cexvQ8huGIy0YgCwHKrm8EVUXUb1Gf7GMbH9wzBuIYyfWbsCgLg0FUb5Npin+h/i+PbjrDMbREtJAgk2ykbWn6WoQxNCJj6zX5hGizIm3ECx12xSJ5pDxnVEpoLZOT1KH5GuajtI3U5a3iSAxSvXZyviAa/xsjsIEpqL0Azgwfc9LjP/jwizkuFD8zktbhntKYu8yShyyQdtpc6xIdhwQHmuWoVISDEI1SRUX6IA86WNEpOVZJ/ybprE39GGkYBHHL1sbHH6270FHEQy3tv99Kg098eJ/VfA1XpRYgiD/Fq0BmyWvFrI3OYzuyn801+7COtC1jHZIDpiNTxvELhbhwF3XMgRz/SX8az+Ey0i+ovhmqpXj/RyFP0CdnYcdAj/hKSVzK4TX26DtLkB8l1fFS9HqEEdvZSmdXHPtC3+g0iV8 t0ncZi3T CYrYQ49ufJlDt6WZwi4MF82jyM2yNzcduTCoihUX+u+wnhG4CMZq5/aVDy07QrhDuPvry34rEWY947Rmx/0Ya/GNe7bCR/p4mE0SmvIhZhn0GayGMUwNI+0tDGWw/jt+hw1ukyGO+ulGVHbGOyF1t24U1FwqLYQxHOvjOwzXH4JfEAh5+blFcuIYqfQKaMd11PcDeyCKZZrwwSoELdPikMfCD9TCvRkn4GGWWRhy96Ngu+3HGwtBo8SBJXSl7weX6hGdvTWPvFVs8P4XFHcTRhCAd8aMdJppajTHGg0tXVGUXU4ljDWSxH71mIvsDY23dd+jvW9lEywlycrlUzYgk1SoxRpcTzebZ4uIPXG9EVMkIEw2XygwjqekzCq/ctBe6SBgs4sVISgCsJREtrx1y4vc2ga7BM/ca9r6c 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: On Fri, Jul 28, 2023 at 8:44=E2=80=AFAM Will Deacon wrote= : > > On Thu, Jul 27, 2023 at 12:34:44PM -0400, Joel Fernandes wrote: > > > On Jul 27, 2023, at 10:57 AM, Will Deacon wrote: > > > =EF=BB=BFOn Thu, Jul 27, 2023 at 04:39:34PM +0200, Jann Horn wrote: > > >> if (READ_ONCE(vma->anon_vma) !=3D NULL) { > > >> // we now know that vma->anon_vma cannot change anymore > > >> > > >> // access the same memory location again with a plain load > > >> struct anon_vma *a =3D vma->anon_vma; > > >> > > >> // this needs to be address-dependency-ordered against one of > > >> // the loads from vma->anon_vma > > >> struct anon_vma *root =3D a->root; > > >> } > > >> > > >> > > >> Is this fine? If it is not fine just because the compiler might > > >> reorder the plain load of vma->anon_vma before the READ_ONCE() load, > > >> would it be fine after adding a barrier() directly after the > > >> READ_ONCE()? > > > > > > I'm _very_ wary of mixing READ_ONCE() and plain loads to the same var= iable, > > > as I've run into cases where you have sequences such as: > > > > > > // Assume *ptr is initially 0 and somebody else writes it to 1 > > > // concurrently > > > > > > foo =3D *ptr; > > > bar =3D READ_ONCE(*ptr); > > > baz =3D *ptr; > > > > > > and you can get foo =3D=3D baz =3D=3D 0 but bar =3D=3D 1 because the = compiler only > > > ends up reading from memory twice. > > > > > > That was the root cause behind f069faba6887 ("arm64: mm: Use READ_ONC= E > > > when dereferencing pointer to pte table"), which was very unpleasant = to > > > debug. > > > > Will, Unless I am missing something fundamental, this case is different= though. > > This case does not care about fewer reads. As long as the first read is= volatile, the subsequent loads (even plain) > > should work fine, no? > > I am not seeing how the compiler can screw that up, so please do enligh= ten :). > > I guess the thing I'm worried about is if there is some previous read of > 'vma->anon_vma' which didn't use READ_ONCE() and the compiler kept the > result around in a register. In that case, 'a' could be NULL, even if > the READ_ONCE(vma->anon_vma) returned non-NULL. If I can be a bit brave enough to say -- that appears to be a compiler bug to me. It seems that the compiler in such an instance violates the "Sequential Consistency Per Variable" rule? I mean if it can't even keep SCPV true for a same memory-location load (plain or not) for a sequence of code, how can it expect the hardware to. In other words, with that kind of caching, the value of the variable goes back in time which will be tough luck for even a fully ordered sequentially-consistent processor!!! > The crux of the issue is that the compiler can break read-after-read > ordering if you don't use READ_ONCE() consistently. Sadly, judging by > the other part of the thread from Nadav, it's fiddly to fix this without > wrecking the codegen. Right. Thanks to you and others for sharing your informative perspective as always, - Joel