On Tue, Feb 18, 2020 at 09:32:20AM -0800, 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. The final result is two > equally sized VMAs where the destination contains the PTEs of the source. > > 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." > > 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> Description and implemenation looks clean/sane for me. Reviewed-by: Minchan Kim <minchan@xxxxxxxxxx> When I review the patch, it seems to be broken with lots of "=20", not sure it's my mail client problem or yours. Anyway, please double check it. Thanks.
