Better late than never, I've at last reviewed the madvise vma merging
going into 2.6.13.  Remove a pointless check and fix two little bugs -
a simple test (with /proc/<pid>/maps hacked to show ReadHints) showed
both mismerges in practice: though being madvise, neither was disastrous.
1. Correct placement of the success label in madvise_behavior: as in
   mprotect_fixup and mlock_fixup, it is necessary to update vm_flags
   when vma_merge succeeds (to handle the exceptional Case 8 noted in
   the comments above vma_merge itself).
2. Correct initial value of prev when starting part way into a vma: as
   in sys_mprotect and do_mlock, it needs to be set to vma in this case
   (vma_merge handles only that minimum of cases shown in its comments).
3. If find_vma_prev sets prev, then the vma it returns is prev->vm_next,
   so it's pointless to make that same assignment again in sys_madvise.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
 
        if (new_flags == vma->vm_flags) {
                *prev = vma;
-               goto success;
+               goto out;
        }
 
        pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
                        goto out;
        }
 
+success:
        /*
         * vm_flags is protected by the mmap_sem held in write mode.
         */
 out:
        if (error == -ENOMEM)
                error = -EAGAIN;
-success:
        return error;
 }
 
         * - different from the way of handling in mlock etc.
         */
        vma = find_vma_prev(current->mm, start, &prev);
-       if (!vma && prev)
-               vma = prev->vm_next;
+       if (vma && start > vma->vm_start)
+               prev = vma;
+
        for (;;) {
                /* Still start < end. */
                error = -ENOMEM;