On Tue, May 19, 2026 at 12:53 PM Lorenzo Stoakes <[email protected]> wrote: > > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote: > > > > > > > I think we either need to fix `fork()`, or keep the current > > > behavior of dropping the VMA lock before performing I/O. > > > > I see. So, this problem arises from the fact that we are changing the > > pagefaults requiring I/O operation to hold VMA lock... > > And you want to lock VMA on fork only if vma_is_anonymous(vma) || > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for > > anonymous and COW VMAs only while holding mmap_write_lock, preventing > > any VMA modification. On the surface, that looks ok to me but I might > > be missing some corner cases. If nobody sees any obvious issues, I > > think it's worth a try. > > Not sure if you noticed but I did raise concerns ;)
Sorry, I didn't realize your first comment was a conceptual objection to this approach of allowing page faults to race with the fork. > > I wonder if you've confused the fault path and fork here, as I think Barry has > been a little unclear on that. > > What's being suggested in this thread is to fundamentally change fork > behaviour > so it's different from the entire history of the kernel (or - presumably - at > least recent history :) and permit concurrent page faults to occur on a > forking > process. > > I absolutely object to this for being pretty crazy. I mean I'm not sure we > really want to be simultaneously modifying page tables while invoking > copy_page_range()? No? > > OK you cover anon and MAP_PRIVATE file-backed but hang on there's > VM_COPY_ON_FORK too.. so PFN mapped, mixed map and (the accursed) UFFD W/P as > well as possibly-guard region containing VMAs now can have page tables raced. Ugh, yeah, I realize now this is a minefield. Resolving all possible races there would not be trivial and might introduce other performance issues. > > That's not to mention anything else that relies on serialisation here (this > would be changing how forking has been done in general) that we may or may not > know about. > > The risk level is high, for what amounts to a hack to work around the fault > issue. > > I suggest that if we have a problem with the fault path, let's look at the > fault > path :) > > So yeah I'm very opposed to this unless I'm somehow horribly mistaken here or > a > very convincing argument is made. So, current approach of dropping locks during I/O sounds like still the best solution. > > > > > > > > > > > > > > > > > > > > > I'd also like to get Suren's input, however. > > > > > > Yes. of course. > > > > > > > > > > > Thanks, Lorenzo > > > > > > Best Regards > > > Barry > > Cheers, Lorenzo
