+++ /dev/null
-From 2b4f3b4987b56365b981f44a7e843efa5b6619b9 Mon Sep 17 00:00:00 2001
-From: Suren Baghdasaryan <surenb@google.com>
-Date: Wed, 5 Jul 2023 18:13:59 -0700
-Subject: fork: lock VMAs of the parent process when forking
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-From: Suren Baghdasaryan <surenb@google.com>
-
-commit 2b4f3b4987b56365b981f44a7e843efa5b6619b9 upstream.
-
-Patch series "Avoid memory corruption caused by per-VMA locks", v4.
-
-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 ~7% 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.
-
-Patch 2/2 disables per-VMA locks until the fix is tested and verified.
-
-
-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 ~7%
-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/20230706011400.2949242-1-surenb@google.com
-Link: https://lkml.kernel.org/r/20230706011400.2949242-2-surenb@google.com
-Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first")
-Signed-off-by: Suren Baghdasaryan <surenb@google.com>
-Suggested-by: David Hildenbrand <david@redhat.com>
-Reported-by: Jiri Slaby <jirislaby@kernel.org>
-Closes: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf51b@kernel.org/
-Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com>
-Closes: https://lore.kernel.org/all/b198d649-f4bf-b971-31d0-e8433ec2a34c@applied-asynchrony.com/
-Reported-by: Jacob Young <jacobly.alt@gmail.com>
-Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D217624
-Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
-Acked-by: David Hildenbrand <david@redhat.com>
-Tested-by: Holger Hoffsttte <holger@applied-asynchrony.com>
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- kernel/fork.c | 6 ++++++
- 1 file changed, 6 insertions(+)
-
---- a/kernel/fork.c
-+++ b/kernel/fork.c
-@@ -662,6 +662,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_set(&old_vmi, 0);
-+#endif
- flush_cache_dup_mm(oldmm);
- uprobe_dup_mmap(oldmm, mm);
- /*
+++ /dev/null
-From f96c48670319d685d18d50819ed0c1ef751ed2ac Mon Sep 17 00:00:00 2001
-From: Suren Baghdasaryan <surenb@google.com>
-Date: Wed, 5 Jul 2023 18:14:00 -0700
-Subject: mm: disable CONFIG_PER_VMA_LOCK until its fixed
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-From: Suren Baghdasaryan <surenb@google.com>
-
-commit f96c48670319d685d18d50819ed0c1ef751ed2ac upstream.
-
-A memory corruption was reported in [1] with bisection pointing to the
-patch [2] enabling per-VMA locks for x86. Disable per-VMA locks config to
-prevent this issue until the fix is confirmed. This is expected to be a
-temporary measure.
-
-[1] https://bugzilla.kernel.org/show_bug.cgi?id=217624
-[2] https://lore.kernel.org/all/20230227173632.3292573-30-surenb@google.com
-
-Link: https://lkml.kernel.org/r/20230706011400.2949242-3-surenb@google.com
-Reported-by: Jiri Slaby <jirislaby@kernel.org>
-Closes: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf51b@kernel.org/
-Reported-by: Jacob Young <jacobly.alt@gmail.com>
-Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217624
-Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first")
-Signed-off-by: Suren Baghdasaryan <surenb@google.com>
-Cc: David Hildenbrand <david@redhat.com>
-Cc: Holger Hoffstätte <holger@applied-asynchrony.com>
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- mm/Kconfig | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
---- a/mm/Kconfig
-+++ b/mm/Kconfig
-@@ -1198,8 +1198,9 @@ config ARCH_SUPPORTS_PER_VMA_LOCK
- def_bool n
-
- config PER_VMA_LOCK
-- def_bool y
-+ bool "Enable per-vma locking during page fault handling."
- depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP
-+ depends on BROKEN
- help
- Allow per-vma locking during page fault handling.
-