Messages in this thread | | | Subject | Re: [PATCH v7 1/2] mm: Add MREMAP_DONTUNMAP to mremap(). | From | Vlastimil Babka <> | Date | Tue, 25 Feb 2020 14:48:31 +0100 |
| |
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@google.com> > Reviewed-by: Minchan Kim <minchan@kernel.org> > Tested-by: Lokesh Gidra <lokeshgidra@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
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.
| |