The quilt patch titled Subject: fork: lock VMAs of the parent process when forking has been removed from the -mm tree. Its filename was fork-lock-vmas-of-the-parent-process-when-forking.patch

This patch was dropped because an updated version will be merged

------------------------------------------------------ From: Suren Baghdasaryan surenb@google.com Subject: fork: lock VMAs of the parent process when forking Date: Tue, 4 Jul 2023 23:37:10 -0700

Patch series "Avoid memory corruption caused by per-VMA locks", v2.

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.

Patch 2/2 disabled 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 ~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/20230705063711.2670599-1-surenb@google.com Link: https://lkml.kernel.org/r/20230705063711.2670599-2-surenb@google.com 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-asy... Reported-by: Jacob Young jacobly.alt@gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D217624 Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first") Acked-by: David Hildenbrand david@redhat.com Cc: Bagas Sanjaya bagasdotme@gmail.com Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: Laurent Dufour ldufour@linux.ibm.com Cc: regressions@lists.linux.dev Cc: Andy Lutomirski luto@kernel.org Cc: Axel Rasmussen axelrasmussen@google.com Cc: Chris Li chriscli@google.com Cc: David Howells dhowells@redhat.com Cc: Davidlohr Bueso dave@stgolabs.net Cc: David Rientjes rientjes@google.com Cc: Eric Dumazet edumazet@google.com Cc: Greg Thelen gthelen@google.com Cc: Hans de Goede hdegoede@redhat.com Cc: Hugh Dickins hughd@google.com Cc: Ingo Molnar mingo@redhat.com Cc: Jann Horn jannh@google.com Cc: Joel Fernandes joelaf@google.com Cc: Johannes Weiner hannes@cmpxchg.org Cc: Kent Overstreet kent.overstreet@linux.dev Cc: Liam R. Howlett Liam.Howlett@oracle.com Cc: Lorenzo Stoakes lstoakes@gmail.com Cc: Matthew Wilcox willy@infradead.org Cc: Mel Gorman mgorman@techsingularity.net Cc: Michal Hocko mhocko@suse.com Cc: Michel Lespinasse michel@lespinasse.org Cc: Mike Rapoport (IBM) rppt@kernel.org Cc: Minchan Kim minchan@google.com Cc: "Paul E. McKenney" paulmck@kernel.org Cc: Peter Xu peterx@redhat.com Cc: peterz@infradead.org Cc: Punit Agrawal punit.agrawal@bytedance.com Cc: Sebastian Andrzej Siewior bigeasy@linutronix.de Cc: Shakeel Butt shakeelb@google.com Cc: Song Liu songliubraving@fb.com Cc: Vlastimil Babka vbabka@suse.cz Cc: Will Deacon will@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org ---

kernel/fork.c | 1 + 1 file changed, 1 insertion(+)

--- a/kernel/fork.c~fork-lock-vmas-of-the-parent-process-when-forking +++ a/kernel/fork.c @@ -686,6 +686,7 @@ static __latent_entropy int dup_mmap(str for_each_vma(old_vmi, mpnt) { struct file *file;

+ vma_start_write(mpnt); if (mpnt->vm_flags & VM_DONTCOPY) { vm_stat_account(mm, mpnt->vm_flags, -vma_pages(mpnt)); continue; _

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