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. Both patches apply cleanly over Linus' ToT and stable 6.4.y branch. [1] https://bugzilla.kernel.org/show_bug.cgi?id=217624 [2] https://lore.kernel.org/all/20230227173632.3292573-30-surenb@xxxxxxxxxx Suren Baghdasaryan (2): fork: lock VMAs of the parent process when forking mm: disable CONFIG_PER_VMA_LOCK until its fixed kernel/fork.c | 1 + mm/Kconfig | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- 2.41.0.255.g8b1d071c50-goog
