From: Hugh Dickins 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. --- 25-akpm/kernel/fork.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN kernel/fork.c~fork-vma-order-fix kernel/fork.c --- 25/kernel/fork.c~fork-vma-order-fix 2004-04-03 03:00:17.645549024 -0800 +++ 25-akpm/kernel/fork.c 2004-04-03 03:00:17.649548416 -0800 @@ -323,7 +323,7 @@ static inline int dup_mmap(struct mm_str /* 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); } _