tools headers UAPI: Sync linux/prctl.h with the kernel sources

[linux-2.6-microblaze.git] / mm / mremap.c

diff --git a/mm/mremap.c b/mm/mremap.c
index ec8f840..47c255b 100644 (file)
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -545,7 +545,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
        if (moved_len < old_len) {
                err = -ENOMEM;
        } else if (vma->vm_ops && vma->vm_ops->mremap) {
-               err = vma->vm_ops->mremap(new_vma, flags);
+               err = vma->vm_ops->mremap(new_vma);
        }
 
        if (unlikely(err)) {
@@ -653,8 +653,8 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
                return ERR_PTR(-EINVAL);
        }
 
-       if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) ||
-                       vma->vm_flags & VM_SHARED))
+       if ((flags & MREMAP_DONTUNMAP) &&
+                       (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
                return ERR_PTR(-EINVAL);
 
        if (is_vm_hugetlb_page(vma))
@@ -730,7 +730,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
         * So, to avoid such scenario we can pre-compute if the whole
         * operation has high chances to success map-wise.
         * Worst-scenario case is when both vma's (new_addr and old_addr) get
-        * split in 3 before unmaping it.
+        * split in 3 before unmapping it.
         * That means 2 more maps (1 for each) to the ones we already hold.
         * Check whether current map count plus 2 still leads us to 4 maps below
         * the threshold, otherwise return -ENOMEM here to be more safe.