Commit 424e44d1 authored by Andrew Morton's avatar Andrew Morton Committed by Linus Torvalds

[PATCH] fork vma ordering during fork

From: Hugh Dickins <hugh@veritas.com>

First of six patches against 2.6.5-rc3, cleaning up mremap's move_vma, and
fixing truncation orphan issues raised by Rajesh Venkatasubramanian. 
Originally done as part of the anonymous objrmap work on mremap move, but
useful fixes now extracted for mainline.  The mremap changes need some
exposure in the -mm tree first, but the first (fork one-liner) is safe enough
to go straight into 2.6.5.



From: Rajesh Venkatasubramanian.  Despite the comment that child vma should
be inserted just after parent vma, 2.5.6 did exactly the reverse: thus a
racing vmtruncate may free the child's ptes, then advance to the parent, and
meanwhile copy_page_range has propagated more ptes from the parent to the
child, leaving file pages still mapped after truncation.
parent 3c7011b3
......@@ -323,7 +323,7 @@ static inline int dup_mmap(struct mm_struct * mm, struct mm_struct * oldmm)
/* insert tmp into the share list, just after mpnt */
down(&file->f_mapping->i_shared_sem);
list_add_tail(&tmp->shared, &mpnt->shared);
list_add(&tmp->shared, &mpnt->shared);
up(&file->f_mapping->i_shared_sem);
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment