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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C300EEB64DA for ; Wed, 5 Jul 2023 17:35:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232713AbjGERfw (ORCPT ); Wed, 5 Jul 2023 13:35:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231305AbjGERfw (ORCPT ); Wed, 5 Jul 2023 13:35:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DCE5319BB; Wed, 5 Jul 2023 10:35:28 -0700 (PDT) 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 6B0106168A; Wed, 5 Jul 2023 17:35:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA8CAC433C7; Wed, 5 Jul 2023 17:35:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1688578527; bh=jGRyJrdK2v3BA1nYN/w3S+y/BR6xFj4oKI6JHQ1FyO4=; h=Date:To:From:Subject:From; b=NJ5Q4OR6ABbiaBgcjIBEd4W6MaS78izpotZqaAmXqxljq3SsZzjNQPKKH+eJ4rQol KS9hD0YLMXFmvZtqHtwPphKmObPJQR1ZdFdvRBx+w5sq52XOEl4ouIYIXmGaVIrbEz RsC3Ge0OFYqANeYdkgzj6h+E6Pxkbbm43YGQvr/E= Date: Wed, 05 Jul 2023 10:35:25 -0700 To: mm-commits@vger.kernel.org, willy@infradead.org, will@kernel.org, vbabka@suse.cz, stable@vger.kernel.org, songliubraving@fb.com, shakeelb@google.com, rppt@kernel.org, rientjes@google.com, punit.agrawal@bytedance.com, peterz@infradead.org, peterx@redhat.com, paulmck@kernel.org, mingo@redhat.com, minchan@google.com, michel@lespinasse.org, mhocko@suse.com, mgorman@techsingularity.net, luto@kernel.org, lstoakes@gmail.com, Liam.Howlett@oracle.com, ldufour@linux.ibm.com, kent.overstreet@linux.dev, joelaf@google.com, jirislaby@kernel.org, jannh@google.com, jacobly.alt@gmail.com, hughd@google.com, holger@applied-asynchrony.com, hdegoede@redhat.com, hannes@cmpxchg.org, gthelen@google.com, edumazet@google.com, dhowells@redhat.com, david@redhat.com, dave@stgolabs.net, chriscli@google.com, bigeasy@linutronix.de, axelrasmussen@google.com, surenb@google.com, akpm@linux-foundation.org From: Andrew Morton Subject: + fork-lock-vmas-of-the-parent-process-when-forking-v3.patch added to mm-hotfixes-unstable branch Message-Id: <20230705173527.BA8CAC433C7@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: fork: lock VMAs of the parent process when forking has been added to the -mm mm-hotfixes-unstable branch. Its filename is fork-lock-vmas-of-the-parent-process-when-forking-v3.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fork-lock-vmas-of-the-parent-process-when-forking-v3.patch This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Suren Baghdasaryan Subject: fork: lock VMAs of the parent process when forking Date: Wed, 5 Jul 2023 10:12:11 -0700 Patch series "Avoid memory corruption caused by per-VMA locks", v3. A memory corruption was reported in [1] with bisection pointing to the patch [2] enabling per-VMA locks for x86. Based on the reproducer provided in [1] we suspect this is caused by the lack of VMA locking while forking a child process. Patch 1/2 in the series implements proper VMA locking during fork. I tested the fix locally using the reproducer and was unable to reproduce the memory corruption problem. This fix can potentially regress some fork-heavy workloads. Kernel build time did not show noticeable regression on a 56-core machine while a stress test mapping 10000 VMAs and forking 5000 times in a tight loop shows ~5% regression. If such fork time regression is unacceptable, disabling CONFIG_PER_VMA_LOCK should restore its performance. Further optimizations are possible if this regression proves to be problematic. This patch (of 2): When forking a child process, parent write-protects an anonymous page and COW-shares it with the child being forked using copy_present_pte(). Parent's TLB is flushed right before we drop the parent's mmap_lock in dup_mmap(). If we get a write-fault before that TLB flush in the parent, and we end up replacing that anonymous page in the parent process in do_wp_page() (because, COW-shared with the child), this might lead to some stale writable TLB entries targeting the wrong (old) page. Similar issue happened in the past with userfaultfd (see flush_tlb_page() call inside do_wp_page()). Lock VMAs of the parent process when forking a child, which prevents concurrent page faults during fork operation and avoids this issue. This fix can potentially regress some fork-heavy workloads. Kernel build time did not show noticeable regression on a 56-core machine while a stress test mapping 10000 VMAs and forking 5000 times in a tight loop shows ~5% regression. If such fork time regression is unacceptable, disabling CONFIG_PER_VMA_LOCK should restore its performance. Further optimizations are possible if this regression proves to be problematic. Link: https://lkml.kernel.org/r/20230705171213.2843068-2-surenb@google.com Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first"= Signed-off-by: Suren Baghdasaryan Suggested-by: David Hildenbrand Reported-by: Jiri Slaby Closes: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf51b@ke= rnel.org/ Reported-by: Holger Hoffstätte Closes: https://lore.kernel.org/all/b198d649-f4bf-b971-31d0-e8433ec2a34c@ap= plied-asynchrony.com/ Reported-by: Jacob Young Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D217624 ) Cc: Andy Lutomirski Cc: Axel Rasmussen Cc: Chris Li Cc: David Hildenbrand Cc: David Howells Cc: Davidlohr Bueso Cc: David Rientjes Cc: Eric Dumazet Cc: Greg Thelen Cc: Hans de Goede Cc: Hugh Dickins Cc: Ingo Molnar Cc: Jann Horn Cc: Jiri Slaby Cc: Joel Fernandes Cc: Johannes Weiner Cc: Kent Overstreet Cc: Laurent Dufour Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal Hocko Cc: Michel Lespinasse Cc: Mike Rapoport (IBM) Cc: Minchan Kim Cc: "Paul E. McKenney" Cc: Peter Xu Cc: Cc: Punit Agrawal Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Song Liu Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Will Deacon Cc: Signed-off-by: Andrew Morton --- kernel/fork.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/kernel/fork.c~fork-lock-vmas-of-the-parent-process-when-forking-v3 +++ a/kernel/fork.c @@ -658,6 +658,12 @@ static __latent_entropy int dup_mmap(str retval = -EINTR; goto fail_uprobe_end; } +#ifdef CONFIG_PER_VMA_LOCK + /* Disallow any page faults before calling flush_cache_dup_mm */ + for_each_vma(old_vmi, mpnt) + vma_start_write(mpnt); + vma_iter_init(&old_vmi, oldmm, 0); +#endif flush_cache_dup_mm(oldmm); uprobe_dup_mmap(oldmm, mm); /* _ Patches currently in -mm which might be from surenb@google.com are fork-lock-vmas-of-the-parent-process-when-forking-v3.patch mm-disable-config_per_vma_lock-until-its-fixed.patch swap-remove-remnants-of-polling-from-read_swap_cache_async.patch mm-add-missing-vm_fault_result_trace-name-for-vm_fault_completed.patch mm-drop-per-vma-lock-when-returning-vm_fault_retry-or-vm_fault_completed.patch mm-change-folio_lock_or_retry-to-use-vm_fault-directly.patch mm-handle-swap-page-faults-under-per-vma-lock.patch mm-handle-userfaults-under-vma-lock.patch