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 7B99FC001E0 for ; Thu, 27 Jul 2023 16:16:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E020F6B0071; Thu, 27 Jul 2023 12:16:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB1ED6B007B; Thu, 27 Jul 2023 12:16:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA0F36B007E; Thu, 27 Jul 2023 12:16:52 -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 B971E6B0071 for ; Thu, 27 Jul 2023 12:16:52 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7EA12A10D6 for ; Thu, 27 Jul 2023 16:16:52 +0000 (UTC) X-FDA: 81057895464.22.893CB49 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 84BD012000E for ; Thu, 27 Jul 2023 16:16:50 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PtppGcCL; spf=pass (imf29.hostedemail.com: domain of "SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690474610; h=from:from:sender:reply-to: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=nN/Y1RPMNWn9SFc67O4hFoJv0L9d2T9vxJbl/Xr3EjU=; b=Gh+V3r2D5D2SOMtwMdb5OtfLyJk+ZspZxO7ptqzaV0dUtd4q/m02JV+BEyAx31Ju05Xgor Fg+8bE2PnH5wYXB2RSQbYZqP71TgsmYNY4FrLnPo6rYKUoaRB0DSo9TEj64UYDEECi6Nui lAj9CDJrL8iGoNXcEysBo1Vk72poOvM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PtppGcCL; spf=pass (imf29.hostedemail.com: domain of "SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690474610; a=rsa-sha256; cv=none; b=fIzJx84EzCGU6BpmTm7mD7Uv5QcukfiFAdsSoeP0PAHpq7WN3DM8Sx5kiIHJHN/B7a5JMx rRCUchIhlrD+kGxAR1SsMnrg7Dwkxj037dmEOn4q9tQ+DPkBbzXKdmWpoNEL1tUJQfp0DG EpUhEc/Ve05H9r42tceYmmKMIqdrzeI= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4AC5A61ECA; Thu, 27 Jul 2023 16:16:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5E7BC433C7; Thu, 27 Jul 2023 16:16:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690474608; bh=5PFG1z3pRVnypkDZVwniaTTH6jGfFJ0ZkRrga6GBt08=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=PtppGcCLFWUUf/6l3hEDtuAkOADoiNfKlY62WB1ZnNOvywfUUG5BZJnncsG79USvK UUGrzGYRRaN1pNqGFXRhvmnLIWHMTxTUi9qpKP/y1k4MDU4E41d/BKeS1qVL3qbj0i BPbIIxdIFir6zajtxBo7tNR5xLZwW89ei5AWiLw25I3UyW8RCcWyHOVu1bzThYPaoM N4uVtmnoGAawjdLIb/+cCm1ajwCHGw3ZIu9qUMXrVCaakKb1q1cgxt4jzjZYIFgAgs WH4AuqlD2gz8UVv4kXhbzcA3O23JW35MwXfnJY5IKtOx+ATVT8wF1KTUEWQofBocGa Pt3q8sSKAVGOQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 48A5DCE0B66; Thu, 27 Jul 2023 09:16:48 -0700 (PDT) Date: Thu, 27 Jul 2023 09:16:48 -0700 From: "Paul E. McKenney" To: Alan Stern Cc: Will Deacon , Jann Horn , Andrew Morton , Linus Torvalds , Peter Zijlstra , Suren Baghdasaryan , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Parri , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Joel Fernandes Subject: Re: [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering Message-ID: Reply-To: paulmck@kernel.org References: <20230726214103.3261108-1-jannh@google.com> <31df93bd-4862-432c-8135-5595ffd2bd43@paulmck-laptop> <20230727145747.GB19940@willie-the-truck> <13dc448b-712e-41ce-b74b-b95a55f3e740@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13dc448b-712e-41ce-b74b-b95a55f3e740@rowland.harvard.edu> X-Rspamd-Queue-Id: 84BD012000E X-Rspam-User: X-Stat-Signature: x5jwwo769ep6zfkefcdczuea37xp8e9m X-Rspamd-Server: rspam01 X-HE-Tag: 1690474610-787056 X-HE-Meta: U2FsdGVkX1/3n1yy3YyGSDyoTCgZ84sQOocDEMFhMimf4s+V8Ift/FhnPWdFXR+lo5uKjBtGz7/k5G7oRLG/IVl77nx2zLSt05DIY5jmTbHCR5r/VaA1PneKF1t5Fg7rtj1eqH2C4kh/dMSStulLvn0bxFkNclUUanmmKtI+qQnr4gxZs3HwPgK5KKwXek66dIO1e9i6BhaZ7cKiVnuIFmx+fsm6wp1UXap+J6xniw65JVL4WYkveysz4VBiU4jh353ZlxfkE+RpRuSJRnRA0GYQ+SMe5/rW7aTWfC3bRQw47RenQ3wM3z+Yt4bThsUS6qn/1ff13xmznypYJ3dxAmOouDeW4TDIYquIDV9exQBquerKJpxbraxmMKjUNrlxZS0PxM5bgmIxdhFV3NGawxH77FfY0cWDlvWf7RtQuzXQO65zq/ebXpOpoHSgvoONDUB/6Bb06BrhFybaJXZPka9xQQbsFn9LZoiDG6kSFMqslltS2YnrTWHn98DQuGkHi9CIOYXiQn5yqtu5Rok3opbLIX5FMknQo4GI3zShLEGNz01XLPgepjSYxSAN9R3cE0L4i4dzag1V+/0LFYeYD+DQS/sAUt3aKrHRrE526+CRVDUgys1qQ/q/2e5M0axVWZa6ayfR72zEfftjzhJx3WPllu2lT/c+byik8rCOJymsPL2ZaXolEkOBnWe7MmU6yxFsckmvDukGol6h0u3I9rVsJ9B+5I+jEW7ZbcvHmN5IMfZcCvRNrr1e4mTjQC2Ft7wmZnidIYtMXejX5e3F7Ecms9oC/778Pthw3DGka+ojoBOFHVWGCAnipiHo7VwkYbt3ts9IkrV3ASPxjA7qH555fk2CvNPY88NWNPPq4agsaXPkrw+FWi1+xfrv8ACJDoD6dJae7rENHHAaXopy2BevTQvCb3GDnGOasSogm9Wa0YTfZPH7NXi8lGjtqqdL024S68c4qbnOnNudWSv dgyJhQd0 JyPxkAAwKNNrcERfgJRe4o/Nz8j6jXlgSiCP+DBvZBHZ3lNSQ1IoSGC+FEJsjlO6MHWRhAQu2GZsoV+GXZlk+UehqUaARbfSlLsRjBfhfuDQJEENgALuelu0KP53VhFtLrO/q1QfVKgK6qdA2+FuGs4rnhpWs/MYLr7JSA3XcMJjGcQZpthxlWcYPtJa4HG3xg64KUmPV+hzww09hfvpl+qh2hZVh3Cp3Uhdfj0xYe8UTQBlwyd4N20U3m2f61zWpGH2ICRxrdFT6AiRq84SOrtPQ65vO4khOfrWj6JwHycY7kH7wZK5T7+S/TIq6Eud2WL7GhSC3SEFFknF5fvk9UZhgDczPdvEojfsyA9ZR5wRm1dFMm/HARuvDXQSPAap++DSAzDYDdftCVESJENo5Fk4OeT0wovon3UiAzAhKjwric1k3p8UhZWCTYlUOGVQL8xqoqzEbXQnhTGWlK9qzMRVnhJlutvshk6Kv+76g4yWQZ2zExy+TqiPI3L/PmJEmaD80BmIhO8yNSf1qfwg9q/IiGZDc/8g1LGZ0B6Ep3LJPnlgoyB3OkzBfpcuyo0hLqlRp45wAo3SGEzqU+cG2k9LDHOv1/BElz0SfhrXkC7pFsWXKHlQd9mh9q8yjQErg9SCu6hju+1EPfyBgu4H15D11zHikt3dtLb3ppTK25XX5/LYbjOdeh9jHOWCXkD7iMrwirZy0MR1UgXK0/gAMkPUsqVrxuKpgNsi6 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 Thu, Jul 27, 2023 at 11:44:02AM -0400, Alan Stern wrote: > On Thu, Jul 27, 2023 at 03:57:47PM +0100, Will Deacon wrote: > > On Thu, Jul 27, 2023 at 04:39:34PM +0200, Jann Horn wrote: > > > > Assume that we are holding some kind of lock that ensures that the > > > only possible concurrent update to "vma->anon_vma" is that it changes > > > from a NULL pointer to a non-NULL pointer (using smp_store_release()). > > > > > > > > > if (READ_ONCE(vma->anon_vma) != 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 = vma->anon_vma; > > > > > > // this needs to be address-dependency-ordered against one of > > > // the loads from vma->anon_vma > > > struct anon_vma *root = a->root; > > > } > > This reads a little oddly, perhaps because it's a fragment from a larger > piece of code. Still, if I were doing something like this, I'd write it > as: > > struct anon_vma *a; > > a = READ_ONCE(vma->anon_vma); > if (a != NULL) { > struct anon_vma *root = a->root; > ... > > thus eliminating the possibility of confusion from multiple reads of the > same address. > > In this situation, the ordering of the two reads is guaranteed by the > address dependency. And people shouldn't worry too much about using > that sort of ordering; RCU relies on it critically, all the time. Agreed. In contrast, control dependencies require quite a bit more care and feeding, and are usually best avoided. But even with the normal RCU address/data dependencies, it is possible to get in trouble. For but one example, comparing a pointer obtained from rcu_dereference() to the address of a static structure is a good way to break your address dependency. (Just yesterday evening I talked to someone who had spent quite a bit of time chasing one of these down, so yes, this is quite real.) > > > 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 variable, > > 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 = *ptr; > > bar = READ_ONCE(*ptr); > > baz = *ptr; > > > > and you can get foo == baz == 0 but bar == 1 because the compiler only > > ends up reading from memory twice. > > > > That was the root cause behind f069faba6887 ("arm64: mm: Use READ_ONCE > > when dereferencing pointer to pte table"), which was very unpleasant to > > debug. > > Indeed, that's the sort of thing that can happen when plain accesses are > involved in a race. Agreed. Furthermore, it is more important to comment plain C-language accesses to shared variables than to comment the likes of READ_ONCE(). "OK, tell me again exactly why you think the compiler cannot mess you up here?" Thanx, Paul