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 868ECC0015E for ; Thu, 27 Jul 2023 16:10:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 105AA6B007B; Thu, 27 Jul 2023 12:10:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B6B46B007E; Thu, 27 Jul 2023 12:10:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E998D6B0080; Thu, 27 Jul 2023 12:10:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D76646B007B for ; Thu, 27 Jul 2023 12:10:53 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7F676B2BEB for ; Thu, 27 Jul 2023 16:10:53 +0000 (UTC) X-FDA: 81057880386.30.B9167EF Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf19.hostedemail.com (Postfix) with ESMTP id 18AA91A002B for ; Thu, 27 Jul 2023 16:10:50 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=HNw8nz0x; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jannh@google.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690474251; 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=X+xfXf+SFs/NOQ0ksDMyvLO9Rn9nyk/jrsGlS1L+bV0=; b=Nsm2Hz722DMTfjL8hv27wMciCfoiDZFtQeomnqXsRSyYzR0Y7q2TEPseKD+/eXHNf7d9MX Z6M7/OjXnt+XhYQiBcJdm3ofMrPmHF4NCbrMR5FvaDfypuhnfVvVwU+XcqFqF+b6FLapvW uK9l7jL5/v5kGvh03nGb8+MRCcDstjg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=HNw8nz0x; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jannh@google.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690474251; a=rsa-sha256; cv=none; b=Qm/PkvHMWLTO6KHoSGi49RjvQz8JRVA40ULlaZsdvW7SATwYaXDhp94bHI0cCF2NK1iqnF pxweZmEo6V0NGbmr/c+VT5q6rpRUXtH1+VzL3rrNvwJ/734EdElfRAlZ+sPtyedrOa3UsH 5lRwe0gTEGnVpEXqG6x/tOdhxFBch78= Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-3fd28ae8b90so84845e9.1 for ; Thu, 27 Jul 2023 09:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690474249; x=1691079049; 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=X+xfXf+SFs/NOQ0ksDMyvLO9Rn9nyk/jrsGlS1L+bV0=; b=HNw8nz0xuMd6I06v9gLe+J2yV8MPgI8J2E5/EZv/9K3qWytBcWtWVxd/j8l3ukt38o oM7WDr546z3dwDSFzyEapFRJ9fefeWObkTYraPGNw+mLrVSFsFWyFJ0SxDIFQlC46Jts BtvyD/9uo3LZXF1kkibNRVOk1ovES2+gn7X8ClzU2sNt854JwBI7jkypTw809782Gpbg NZ2dDpFhYyaAlXpWOo92DRA4/ABK/KJhmP0aKtOulHfSiH8OfBmIR2ifp4mxbpzP0drz LqQX8wBjQCuHL186Lmb5WfDmCq/npG9nCajsEEhBCVYJUK9iwjTc1E35hiq+nUKvNtW0 Z/tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690474249; x=1691079049; 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=X+xfXf+SFs/NOQ0ksDMyvLO9Rn9nyk/jrsGlS1L+bV0=; b=E4C+n3Kx1Xy2xJlcpBCEXlbCDWK+HMbQUivIYsvq8FwT+9qYzRAgaXLwJdioHtkfRw +nnVWaszhP6AFOqHIQaAKSONmAO6MIAEF/Nf7ivNr93AOPJ+Z1JtTJy4iWPaI1DMIpWq z4dVhg3dZ/KNxR/tt61UPUVSp3WR1o+YoQOS3b0esJvnp1N0eN6rRPWG0ek01dFrKuDi 0xMSnUhoa59cGFojgn91pJGrPeyG4W5r8K8J8rsOBcNrYI+Z61eWhVccJVkKCwsZcW+A lujocWNIvyvieC/As/mp3wSO9SnwSu6IiymoVorDZg4/GfwGvqcLUct9SkkoYoy2rV1t A7fQ== X-Gm-Message-State: ABy/qLaSJ63PFWtDT5brCMEJZxzaNYho9nqL66e3XQ9mk/35vrKc7Gwe 56xnV5sj+xg9b2Dhvk3DGEZjKLcrL+WY0MuyVM3f+A== X-Google-Smtp-Source: APBJJlG5VES8QxpxVaDTzmDFfw3ngkuISlX1JRoJU8AZ/7z1v8YbcFTVffCgNO7Uu39CC/q8qvlVgovVBaTNMEm38V8= X-Received: by 2002:a05:600c:4fcc:b0:3f7:e4d8:2569 with SMTP id o12-20020a05600c4fcc00b003f7e4d82569mr88727wmq.5.1690474248653; Thu, 27 Jul 2023 09:10:48 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <13dc448b-712e-41ce-b74b-b95a55f3e740@rowland.harvard.edu> From: Jann Horn Date: Thu, 27 Jul 2023 18:10:12 +0200 Message-ID: Subject: Re: [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering To: Alan Stern Cc: Will Deacon , paulmck@kernel.org, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 18AA91A002B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 7wi7cgenteu8amac13ibtpojfmmw64tu X-HE-Tag: 1690474250-295079 X-HE-Meta: U2FsdGVkX1+0hoaFwQWv5wWp8NN4YoMxe+sEQzuhz+8xekGFcxC8PEiSBqbBwdJqqYuPdz/dljsencqsmPWZ4m+7iGzcZCAYk+bO6VMv+4m7rfokxRSHQgcW59wA7hBkQvNEHR07Mq3wpxeFFoa4053kHXihTAkElBVdSMFok1scwiQjWF+MGlBNxyJ02y7ux0yWDhSjU+CNPm+ohfN4c/lrBM4MGKCnGkRSXX6De8hu73tL67H8vNWALYYxFLB1dXT0rPEVCOGIsGG6KT3KndxiaRhaRAoyQrBkoG5CqUqzrGO/KDLwodBVV8G7lPL5Vsty8cBKwSq0nBBht121Td2un5Cz0DxxnVLqmRjeYuCtmM+gDAFn4Pp4bugtl/XIWt0Ba3ZDhEw/u6/NYWW92kLh/FiPH14yTdJZEruAfm9nKIhQffYqiwxW+NrIltRhNlS9te1OPiJPsNexh7DtsF5FPDk0ZF93REMJqNcfafgK5hXo+aR0cAwGUdcK91u4YuCyCAv5nwHMFAZJEdXTBz+Ws8RZ8FEP66CTi9rZL5bKOwxYPYucQs7hQE9Z/Exf1vtOsKwJW4XqiwJHKKQKQpj1ZkH1ULu1/yzdAGXLOvkeLafXRtBFUwkZNVdgc4GXw+kVm1/kpHFAuPg7vkWpeFzlXgx3MnBMnvTJ4nuL7KGDWbhSHJmmnazyuLf0xu2G/U4O3HbquNH5SWiDheFkb7lPdpfJRYmNBNXMj8EoWFuS6tl457vCm13TpT3VBJ7WHpSTjO8YOuV4akLG6IJY1IQw2pfclY+fDf6WKJYc0rPKrlOGANS6XlEcWPQ77oHoU4MlJ5Wv8PFx97apLL+/eVPCN6svmfqFUj5J8yYzDRLKJF8HIH19JbkGTUmKXp4N4lNCXWoeCPnivxH95QAwdj1emxhGHxFzIz9tA+fWlKC+qgHGTNEVIEAQJNH1qcGMLnC0o7r+1DLTnzGYMPF h5xasd42 R21skx1+Nb/jh7rWpet+ULDWO9Guz0s5ElSzbvCsQiberHncuR3hNBZQDz5eQhwZN9GuNcpJifKYDEgXVM217DxEvIbO4/7H/pJTsb8dm9xnnDF1m1ziYlR+ECnAion1ohM2i+EkfDJ+lUS3n2NJmhKJNGP8aHEJr1D10UCfxbbyXuJWtaOM//yomvlCNK7gWOO4deFw61xElQFqQa8sTSP94gPgMHDL7fyCyDg4l7ZoSLBqYlutJLMi0d/Ln14oc5Wob+srgQdJ5n4mGTnMUlVkc4bPZbH2JNCkIH0LMH2+gJaQ/THUWzBSv+FzDGpc3wu6cWczVvLQZyX2PuLLAUUnU1wlqCaWXBRFr 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 5:44=E2=80=AFPM 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) !=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; > > > } > > 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().