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 C21CFC0015E for ; Wed, 26 Jul 2023 23:19:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C3366B0078; Wed, 26 Jul 2023 19:19:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 373C46B007D; Wed, 26 Jul 2023 19:19:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23AD26B007E; Wed, 26 Jul 2023 19:19:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0DC416B0078 for ; Wed, 26 Jul 2023 19:19:05 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B88F7B136A for ; Wed, 26 Jul 2023 23:19:04 +0000 (UTC) X-FDA: 81055330608.23.95E1166 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id C173DC0005 for ; Wed, 26 Jul 2023 23:19:02 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KwAO6H00; spf=pass (imf28.hostedemail.com: domain of "SRS0=Omw2=DM=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=Omw2=DM=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=1690413542; 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=PJtV/Tp2I0/XX1+DqrcQUfTlHkzuDOXZR9nwTj4nk1Q=; b=s+EszS+mzXjztll6egjGUrEhzWJdF5cANFPv/Y3K1wpBJVPcDB2mBwBZPa0Zu9HbkqzCPG PI6b5fgX2AylLaLCcYtv0ZRehsDDPYhe2CJa0eeuQ6ksxfDfOhw+oLQOoPkFxgKRGAf/kJ fq74Xutbtrc6sHISIbo3t3TsLI8JYmo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KwAO6H00; spf=pass (imf28.hostedemail.com: domain of "SRS0=Omw2=DM=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=Omw2=DM=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=1690413542; a=rsa-sha256; cv=none; b=5p1CvQgrhU6aPPx41tWMBDvoVVJIMCckZIzyo64TSHJKKUpGZBfr53auseJDeMCUvd6vrV aM5/FD7fGR4ScjA/kfWvlLn//chma8BU6GjSRU3/yPCOrNmnu5djBWp2EIGUEutt8zmuuX z9KgP1jIfAuO4uHHSnlbsJTGG44HQyc= 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 D38D861C9C; Wed, 26 Jul 2023 23:19:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CBE5C433C8; Wed, 26 Jul 2023 23:19:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690413541; bh=OyzZD5MHFQ71H/7riF0ScWcazkzij12xVCuT2YfRhl0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=KwAO6H00AZupIs+wOw57k4SWypFeb4kiLtPomsQBCR8dp2v6ehfiCEWYqQdg/AmH6 49ifx71i+yGverkc41Ppyyv5imfJi8Zkw2Fhb3HvQLCCnpGY+4UpVHVcFFznJN2c7C TAgQSvYPhzj9kqdOxU8fdIZ/mhFQOtg67ZUqps9sPzuINfheocfcUJtmbV/0D5X5TZ XH9jGEBN7S4PQwd92OEINDKEwHleXv4DjNcwtCUxlNNeCPLC9PMBShRzAZICGk/cWg wU2GB+/5u3jo1MYNyKjCkjBedi58jSpdiHR6Mx7u/g17kPzgr1KMVLsMaFrg+5JCG5 VcL9Hwff2A0/A== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id B5E83CE0AD7; Wed, 26 Jul 2023 16:19:00 -0700 (PDT) Date: Wed, 26 Jul 2023 16:19:00 -0700 From: "Paul E. McKenney" To: Jann Horn Cc: Andrew Morton , Linus Torvalds , Peter Zijlstra , Suren Baghdasaryan , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alan Stern , Andrea Parri , Will Deacon , 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: <31df93bd-4862-432c-8135-5595ffd2bd43@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20230726214103.3261108-1-jannh@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230726214103.3261108-1-jannh@google.com> X-Rspamd-Queue-Id: C173DC0005 X-Rspam-User: X-Stat-Signature: p1d57xxdztwsspqbgwqcigd7yc1r56in X-Rspamd-Server: rspam01 X-HE-Tag: 1690413542-609168 X-HE-Meta: U2FsdGVkX1/nIBemcqK5AjiAPXtfrRwqP6Y1clySemgKGj/VkiICG2aMdJiGcST+aHGB+VLiHQAKA7vkR9i0/8L7EcZxnZzAjnrHni5qEcc3NUyJs558vhuSw7jC6zy1PxzgXJVqV1PVGvn5kJsgj8WihhBjps2CrDBi5kB7ozzzrMW+ZEgYYK5R2W4hGvg/aqLs6E+ukxmk0disr1FZYED+OHn0QJ5BVX4jbb2ODQhHaG5ZnKNU+UWwmpL/8ZkOSrBY4sT265x4Zh+UoyZ8KFJGq3uGOmA3WJDXYWFUgWk8uLg1t6pTjzSjBSMGaNy7TjBOOMFx4R3kcGmxQCmRIsGrGg6zT3cPKbKugEoUYv30SkL+vcZBDAPTolIC6eEUSns01No6aRGP/P5ujbylNGCSgeTm1F10LzafwmrUAOyOWxxx1ntm7v46qyECqNOtl+oI4LpFHB7xL1ZJ3msZrKzx9BcIEL3ZYjXa0s1GREGwIX6ktN8SrnXW5HWjyNZ1QAHQYt4lQULTeMDUCR48Twr1G6plml48oajM+SvP6LXGdRH4vXJGKa5GprcGsHDu6AMnS25aMaav1J0W/F7ss8EA37BHG50IAV4aKULL//BjfucEOwOYrlxK6jdQBr4SYNHJ+r8WRfchnOldpVseSIXJV+GNSU6Cpw5MvQbvvARVeLEr05PxqHTJak+LXpB74WcUodtR5FcW4A1dkWN1mZoFEh1XX2KVjJt/6GsUYiUKxkB2bK5YRr3yUi4cENUYNEdiTvZm7GCFXVFDmspPLKRBPURgCE1Kadn3Mg6BDXIUSRQbWSjBYjPCTfV11mUkmgqqYbzxbhaKtGWB+DO+htf3k1/GcoCJbsne//cAwekOZy2LoHqaBPRIMxk/Vq93WreGszxXzMxPhJ3r3aDDRLC82MrjlKJ+4KUJr2M4UJCEj3eO+zVLjS6t8Ye9tO/awYb0fG4kwVez8OAc4kS f8+7NN4t lCIsYuPXo9I0xqoMFkSMU5Baw5Mc3/gZ3RqgIY2pUzOUt+5gj7NCXsXlTkHAxpNGpD4aeTmeHqA7ol9Y1RpaEAhR6c3BGzLLIiWjSkT5y3Y5rHxL/TFnXlXnpEkyGaY3Kn+TJoh+zaval210Y1D9CmVUeWzOqm8I4B321ypSntF5IlFW5OKZcy+MN1ZmGqNgRMt23jYazQrLU/aBhrFfi6h/6jRLI8jRn5/P+cQMH+qn8NwQrxsiMlJg27QQDvQOox7wEHNsnIyJJF5Rkur+lBTwd/89HwY27KGhsuSr3J3RPqPFFYcUoo0NWprHu5yKHGRwiglFT8mW4o6OIrD0mv3hyfe1JZWBN/AW0Uq6vMSuK5JT8UVts6geMk3M16nS2/so+xvLPRB1sucpgwoZkWvxx+McfiZiQ/uUMGy4UleQTofmrtvdTv2ouoY+TtntQ5LedOcSh695dEX3yIuUwds96P7a7O/MErC4zwFMW8jAs2+SrmlfVicZVxzvRx+TUJmpNft6AmUqDAKlf0rmtlbKKUgTY4Ijtzr1r5X+ySwYyn+fK8a7me5a1iVZGutmPzJAkzgeqDNAQN/hnA8WKy+ueFQ6qHzqrcTaHkKrjM6V52++zUbZF6uXgu0GSOR0bJ1l9HbA2qtYi6gSwHmfYwne3rBsZtuEUB6Q2gh76QDtAYTwWHLbg948QDDXzhrHUolBWxkpCp0sZFtThnBfwGaub7sC49CdWb++9nQR8s2/rdiPut1/iyw2RQ1YRAxMSwwF1 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 Wed, Jul 26, 2023 at 11:41:01PM +0200, Jann Horn wrote: > Hi! > > Patch 1 here is a straightforward fix for a race in per-VMA locking code > that can lead to use-after-free; I hope we can get this one into > mainline and stable quickly. > > Patch 2 is a fix for what I believe is a longstanding memory ordering > issue in how vma->anon_vma is used across the MM subsystem; I expect > that this one will have to go through a few iterations of review and > potentially rewrites, because memory ordering is tricky. > (If someone else wants to take over patch 2, I would be very happy.) > > These patches don't really belong together all that much, I'm just > sending them as a series because they'd otherwise conflict. > > I am CCing: > > - Suren because patch 1 touches his code > - Matthew Wilcox because he is also currently working on per-VMA > locking stuff > - all the maintainers/reviewers for the Kernel Memory Consistency Model > so they can help figure out the READ_ONCE() vs smp_load_acquire() > thing READ_ONCE() has weaker ordering properties than smp_load_acquire(). For example, given a pointer gp: p = whichever(gp); a = 1; r1 = p->b; if ((uintptr_t)p & 0x1) WRITE_ONCE(b, 1); WRITE_ONCE(c, 1); Leaving aside the "&" needed by smp_load_acquire(), if "whichever" is "READ_ONCE", then the load from p->b and the WRITE_ONCE() to "b" are ordered after the load from gp (the former due to an address dependency and the latter due to a (fragile) control dependency). The compiler is within its rights to reorder the store to "a" to precede the load from gp. The compiler is forbidden from reordering the store to "c" wtih the load from gp (because both are volatile accesses), but the CPU is completely within its rights to do this reordering. But if "whichever" is "smp_load_acquire()", all four of the subsequent memory accesses are ordered after the load from gp. Similarly, for WRITE_ONCE() and smp_store_release(): p = READ_ONCE(gp); r1 = READ_ONCE(gi); r2 = READ_ONCE(gj); a = 1; WRITE_ONCE(b, 1); if (r1 & 0x1) whichever(p->q, r2); Again leaving aside the "&" needed by smp_store_release(), if "whichever" is WRITE_ONCE(), then the load from gp, the load from gi, and the load from gj are all ordered before the store to p->q (by address dependency, control dependency, and data dependency, respectively). The store to "a" can be reordered with the store to p->q by the compiler. The store to "b" cannot be reordered with the store to p->q by the compiler (again, both are volatile), but the CPU is free to reorder them, especially when whichever() is implemented as a conditional store. But if "whichever" is "smp_store_release()", all five of the earlier memory accesses are ordered before the store to p->q. Does that help, or am I missing the point of your question? Thanx, Paul > - people involved in the previous discussion on the security list > > > Jann Horn (2): > mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock > mm: Fix anon_vma memory ordering > > include/linux/rmap.h | 15 ++++++++++++++- > mm/huge_memory.c | 4 +++- > mm/khugepaged.c | 2 +- > mm/ksm.c | 16 +++++++++++----- > mm/memory.c | 32 ++++++++++++++++++++------------ > mm/mmap.c | 13 ++++++++++--- > mm/rmap.c | 6 ++++-- > mm/swapfile.c | 3 ++- > 8 files changed, 65 insertions(+), 26 deletions(-) > > > base-commit: 20ea1e7d13c1b544fe67c4a8dc3943bb1ab33e6f > -- > 2.41.0.487.g6d72f3e995-goog >