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 68A26C0015E for ; Thu, 27 Jul 2023 16:17:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 047526B007B; Thu, 27 Jul 2023 12:17:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F395F6B007E; Thu, 27 Jul 2023 12:17:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E01E56B0080; Thu, 27 Jul 2023 12:17:34 -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 D3C536B007B for ; Thu, 27 Jul 2023 12:17:34 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7C69F1CA270 for ; Thu, 27 Jul 2023 16:17:34 +0000 (UTC) X-FDA: 81057897228.15.6D68574 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 84AC210000F for ; Thu, 27 Jul 2023 16:17:32 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=faTWUviF; spf=pass (imf05.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=1690474652; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Us4lUVLVedm6xAFRTc8AlS0TvSELhCDzsdgg+Zs/koU=; b=x7PgJCHYLzJx0T9xbRr0LOFqiL2vIzvXezjaQQQWXjPaXx6rhmYVyr8wIcPWf+hnYqFgv4 I8WueIvQQ/uIfs7Sc8rB2yFDWYIbARl4ehu+Hej0e/xfAzS4DOdH6yKSpmMYLkU7pRbrRv /GUEB6AHD0BDGBrblTWkXb03ASwuVyc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=faTWUviF; spf=pass (imf05.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=1690474652; a=rsa-sha256; cv=none; b=JgdYbyYTVz3Me/TQt4GDZSTwEJy0Wg3xDxbpHlb/zq9oeKleyLIT5FQmafnOaQXWdFQNVl SZ3p5s3vIQLevJSZNUMtq2KW4sX2+Hs7EfnDoVB/GsGgbjpctt6NsEhWihHuzR18z3i6TN aJsRIwf4n1EUFL2TlyOOmJDexMShDfs= 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 964FE61EC7; Thu, 27 Jul 2023 16:17:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00136C433C7; Thu, 27 Jul 2023 16:17:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690474651; bh=HSafwvhjnkUwgp5hjhjpcPldOQdA7vHMNcgZDr3m1Hg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=faTWUviFoFcFudqdn2L/tCQOu+vuYIqf8174cKaN9DOitIXCkTbqmegX3ENgpyEA0 LPnAO8s/kez5qiNoxgsf/fOQ0TJ+4TCC0vOYAzibiWKt1LHUAUTf2HkW8esova1X60 p9JJq+sBM9Nxz1P+BmahmxRobEEyE6JJdzpnPkij2q6s4am0StfXxmsZLD0d7i4KT9 luDYvuSwxFzLZyR8PDKz8qpYYUS6CJPPtyw3K/hmg4Nan7ks+BaS3jEoVuNN7yQZ3f AIDWY0whvwyk3jGPZnwLw7VZrdgfD0EBRqklqvozIUDvmijGsxtRqLUNZbmOjYhqkh QY0RAx1a60u/A== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 9839CCE0B66; Thu, 27 Jul 2023 09:17:30 -0700 (PDT) Date: Thu, 27 Jul 2023 09:17:30 -0700 From: "Paul E. McKenney" To: Jann Horn Cc: Alan Stern , Will Deacon , 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: <696f108e-ae73-4795-aae4-56a895226dfa@paulmck-laptop> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 84AC210000F X-Rspam-User: X-Stat-Signature: b9nnzww7akhkr6oez6by9j764cez6ey9 X-Rspamd-Server: rspam01 X-HE-Tag: 1690474652-572253 X-HE-Meta: U2FsdGVkX1/8MVB9am/i/+01ouzpmKIu4zV3Iqn4I1RckWVTEmvEOLeA54pFS2dC9d8BU1mI9HDCSyGftPWUDT6L933p3wijvx/cIN/BUfeERpWoKvWcwvnSTo4+DULVKQEYnmRJXbk+t6FhRZYIDXjkmuJn26Kwmg3as2bPKexmPY+8n1PqsRdQCke/kR95jRavDwMIkVrP2hg6QdBvN0auD6BakTIFIeIWsuPBYhWyp3k5lJwHpF/9+9iyfljdO3W2vwiVAV/arH/rIIlr/AMelgt6YHPUCGZT58le8OoW+gq7KbV2d4C6snDQLEOUg3Mb9yGH+/NuwPs5IMmjV/yzlvtO87H1IXxfZV7ytAAPY42UUw/KvnhKtcp9g2JKLQGOlv10e6eJicp/s0KXUfSBkNj6tbAF0r+bNnB9Wg0dyuM5AwH1fqRKHMN17sGLbiBXKHiurkz/iL11bjZJekhQtp1MZSQwk6I1UyntFKdr/Sw0y9Iyui8Mo6ZaFSwFiZZfdrKB/pJIDoCn29ujsEEt/Q6EEVUoxCRevcKQF+2JyNl844Nc90uUJn0rzeWmwmOwkD/o5+tpZ/C6EA6GbCGUj36uAkv/4cMt/RlAEyPFSyY4PXQwqK+eb+qug+MZQ9Eu6PEGJJ/wjWPRDq9BgVqgFQ8bteXXQd3sHPXGsxHGizTxRm/ZQGa0mFD8VatC0bXGVbvUTwLWJe6zeRwmlT0zsPbnimYwPdZiN/LpziAArKxctTXLSx9Tr8SADadIAcCfsTBcEGlGGh4wT389hxCbKhnzFL835eFEnj7H0cW6H8RVHIB9ioMAbqs8WTtc5aHvL+9aVN80YilmICyZ5VguFI3IWYhAOa9zVdv5USaKkTmtB2Rf3Q08d7pOtJ8T1Km7JdrqymzumO3VwmcuJNK1Usvk67SCNOhcbWM1sSHAvUoErgBICpMaPSPezcojh/uaQz0Ft4xRTmHT/zp U+JgggH1 jDYIMbUnCsNn6Xd1rk5TAa7ZSkHujQiTuQZ2Mc9TO9Az/9cDHiauNLArD5MJMigTNMo5fsXvc7EeT7oNWpK/XeLYLTdklKOaZz1PWEUK4lJ9GELkbbt9nkBK5c/UBFaqa4SG/UhKh0YO8Hxdr0ckvPqwa2aUp7oa8Uj9vK8MpnIjgIqtdaliXlS4FGhFBPJJerZpV0TNWuR38wEBEJ7nLKA92nn9z8BU6vOGGyWKwGtsgI0q9Oc6ovy2bre4+RKJlVLS+h8RKLsH1ynjFbct2PDbOVSsd+t2Z3y++PpCsHRFNDopWKYyqbgYbRucuLGRCZw5jnv90KlOQZ+B4A+a9qUVHa1KEQBpqz3g+nUDkLoEBumu+UTWKEnSuvhBqKjTjlxdxOgsZkeeoIMtQnGer0YVqGHscCBGrFuKfQTMBt+EtN545Snz7MxvcO+PrXDdYHm5gsCPc0/RBTZzhz1+7v9guVLfTX79tyJm4VOzvxfJSOt6IORCWit6ObUy41rC44LzlJ/rYklLifkLYF8letGnvmat9ZczW30m9lxvYLbo4GwkP5Ur7Qmre/dMkMFqPZh2gdwMS6knNlnEtRGk97e4PldvTI6xAIboz8iUzViw5cUEbi03SBm+mZ6ToTKWOerCKlxBsGAlmKizm0/Z7u3mD2ZZ+CFmt+WmOmWxKw4l7ENYvpjgbdVj5oo4DbPs1YX9Vx0bhD1XTRJ1DNjLNHI8t2kLfSZiRwGpP 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 06:10:12PM +0200, Jann Horn wrote: > On Thu, Jul 27, 2023 at 5:44 PM 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. > > Yes, exactly. The READ_ONCE() would be in anon_vma_prepare(), which is > a helper used to ensure that a VMA is associated with an anon_vma, and > then the vma->anon_vma is used further down inside the fault handling > path. Something like: > > do_cow_fault > anon_vma_prepare > READ_ONCE(vma->anon_vma) > barrier() > finish_fault > do_set_pte > page_add_new_anon_rmap > folio_add_new_anon_rmap > __page_set_anon_rmap > [reads vma->anon_vma] > > Anyway, I guess I'll follow what Paul and Matthew said and go with > smp_load_acquire(). I thank you now, and you will thank youself later. ;-) Thanx, Paul