On Tue, Jul 04, 2023 at 09:18:18AM +0200, David Hildenbrand wrote: > > At least the reproducer at > > https://bugzilla.kernel.org/show_bug.cgi?id=217624 is working now. But > > I wonder if that's the best way to fix this. It's surely simple but > > locking every VMA is not free and doing that on every fork might > > regress performance. > > > That would mean that we can possibly still get page faults concurrent to > fork(), on the yet unprocessed part. While that fixes the issue at hand, I > cannot reliably tell if this doesn't mess with some other fork() corner > case. > > I'd suggest write-locking all VMAs upfront, before doing any kind of fork-mm > operation. Just like the old code did. See below. Calling fork() from a multi-threaded program is fraught with danger. It's a rare thing to do, and we don't need to optimise for it. It does, of course, need to not crash. But we can slow it down as much as we want to. Slowing down single-threaded programs calling fork is much less acceptable. https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html
