On 2/21/20 6:42 PM, Brian Geffon wrote: > When remapping an anonymous, private mapping, if MREMAP_DONTUNMAP is > set, the source mapping will not be removed. The remap operation > will be performed as it would have been normally by moving over the > page tables to the new mapping. The old vma will have any locked > flags cleared, have no pagetables, and any userfaultfds that were > watching that range will continue watching it. > > For a mapping that is shared or not anonymous, MREMAP_DONTUNMAP will cause > the mremap() call to fail. Because MREMAP_DONTUNMAP always results in moving > a VMA you MUST use the MREMAP_MAYMOVE flag, it's not possible to resize > a VMA while also moving with MREMAP_DONTUNMAP so old_len must always > be equal to the new_len otherwise it will return -EINVAL. > > We hope to use this in Chrome OS where with userfaultfd we could write > an anonymous mapping to disk without having to STOP the process or worry > about VMA permission changes. > > This feature also has a use case in Android, Lokesh Gidra has said > that "As part of using userfaultfd for GC, We'll have to move the physical > pages of the java heap to a separate location. For this purpose mremap > will be used. Without the MREMAP_DONTUNMAP flag, when I mremap the java > heap, its virtual mapping will be removed as well. Therefore, we'll > require performing mmap immediately after. This is not only time consuming > but also opens a time window where a native thread may call mmap and > reserve the java heap's address range for its own usage. This flag > solves the problem." > > v6 -> v7: > - Don't allow resizing VMA as part of MREMAP_DONTUNMAP. > There is no clear use case at the moment and it can be added > later as it simplifies the implementation for now. > > v5 -> v6: > - Code cleanup suggested by Kirill. > > v4 -> v5: > - Correct commit message to more accurately reflect the behavior. > - Clear VM_LOCKED and VM_LOCKEDONFAULT on the old vma. > > Signed-off-by: Brian Geffon <bgeffon@xxxxxxxxxx> > Reviewed-by: Minchan Kim <minchan@xxxxxxxxxx> > Tested-by: Lokesh Gidra <lokeshgidra@xxxxxxxxxx> Acked-by: Vlastimil Babka <vbabka@xxxxxxx> Thanks. > diff --git a/mm/mremap.c b/mm/mremap.c > index 1fc8a29fbe3f..8b7bf3845e50 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -318,8 +318,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > static unsigned long move_vma(struct vm_area_struct *vma, > unsigned long old_addr, unsigned long old_len, > unsigned long new_len, unsigned long new_addr, > - bool *locked, struct vm_userfaultfd_ctx *uf, > - struct list_head *uf_unmap) > + bool *locked, unsigned long flags, > + struct vm_userfaultfd_ctx *uf, struct list_head *uf_unmap) The usage of MREMAP_DONTUNMAP directly in the "flags" parameter seems weird for generically named vma manipulation functions, but as they are all local to mremap.c then it's probably fine.
