On Thu, Nov 06, 2025 at 10:46:14AM +0000, Lorenzo Stoakes wrote: > It's useful to be able to force a VMA to be copied on fork outside of the > parameters specified by vma_needs_copy(), which otherwise only copies page > tables if: > > * The destination VMA has VM_UFFD_WP set > * The mapping is a PFN or mixed map > * The mapping is anonymous and forked in (i.e. vma->anon_vma is non-NULL) > > Setting this flag implies that the page tables mapping the VMA are such > that simply re-faulting the VMA will not re-establish them in identical > form. > > We introduce VM_COPY_ON_FORK to clearly identify which flags require this > behaviour, which currently is only VM_MAYBE_GUARD. > > Any VMA flags which require this behaviour are inherently 'sticky', that > is, should we merge two VMAs together, this implies that the newly merged > VMA maps a range that requires page table copying on fork. > > In order to implement this we must both introduce the concept of a 'sticky' > VMA flag and adjust the VMA merge logic accordingly, and also have VMA > merge still successfully succeed should one VMA have the flag set and > another not.
Perhaps we should separate this patch into two? It looks like we're doing two things at once for no great reason. But it's a bit of a sticky situation... > > Note that we update the VMA expand logic to handle new VMA merging, as this > function is the one ultimately called by all instances of merging of new > VMAs. > > This patch implements this, establishing VM_STICKY to contain all such > flags and VM_IGNORE_MERGE for those flags which should be ignored when > comparing adjacent VMA's flags for the purposes of merging. > > As part of this change we place VM_SOFTDIRTY in VM_IGNORE_MERGE as it > already had this behaviour, alongside VM_STICKY as sticky flags by > implication must not disallow merge. > > As a result of this change, VMAs with guard ranges will now not have their > merge behaviour impacted by doing so and can be freely merged with other > VMAs without VM_MAYBE_GUARD set. > > We also update the VMA userland tests to account for the changes. > > Note that VM_MAYBE_GUARD being set atomically remains correct as > vma_needs_copy() is invoked with the mmap and VMA write locks held, > excluding any race with madvise_guard_install(). > > Signed-off-by: Lorenzo Stoakes <[email protected]> Overall the patch LGTM. Feel free to add: Reviewed-by: Pedro Falcato <[email protected]> and maybe print it out on a sticker. -- Pedro
