The patch titled Subject: mremap: don't do mm_populate(new_addr) on failure has been removed from the -mm tree. Its filename was mremap-dont-do-mm_populatenew_addr-on-failure.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Oleg Nesterov <oleg@xxxxxxxxxx> Subject: mremap: don't do mm_populate(new_addr) on failure move_vma() sets *locked even if move_page_tables() or ->mremap() fails, change sys_mremap() to check "ret & ~PAGE_MASK". I think we should simply remove the VM_LOCKED code in move_vma(), that is why this patch doesn't change move_vma(). But this needs more cleanups. Signed-off-by: Oleg Nesterov <oleg@xxxxxxxxxx> Acked-by: David Rientjes <rientjes@xxxxxxxxxx> Cc: Benjamin LaHaise <bcrl@xxxxxxxxx> Cc: Hugh Dickins <hughd@xxxxxxxxxx> Cc: Jeff Moyer <jmoyer@xxxxxxxxxx> Cc: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> Cc: Laurent Dufour <ldufour@xxxxxxxxxxxxxxxxxx> Cc: Pavel Emelyanov <xemul@xxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- mm/mremap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff -puN mm/mremap.c~mremap-dont-do-mm_populatenew_addr-on-failure mm/mremap.c --- a/mm/mremap.c~mremap-dont-do-mm_populatenew_addr-on-failure +++ a/mm/mremap.c @@ -578,8 +578,10 @@ SYSCALL_DEFINE5(mremap, unsigned long, a ret = move_vma(vma, addr, old_len, new_len, new_addr, &locked); } out: - if (ret & ~PAGE_MASK) + if (ret & ~PAGE_MASK) { vm_unacct_memory(charged); + locked = 0; + } up_write(¤t->mm->mmap_sem); if (locked && new_len > old_len) mm_populate(new_addr + old_len, new_len - old_len); _ Patches currently in -mm which might be from oleg@xxxxxxxxxx are mm-introduce-vma_is_anonymousvma-helper.patch mmap-fix-the-usage-of-vm_pgoff-in-special_mapping-paths.patch mremap-fix-the-wrong-vma-vm_file-check-in-copy_vma.patch mm-mpx-add-vm_flags_t-vm_flags-arg-to-do_mmap_pgoff.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html