Re: [PATCH] anobjrmap 7/6 mremap moves

[Rajesh Venkatasubramanian]

> +struct vm_area_struct *copy_vma(struct vm_area_struct *vma,
> +	unsigned long addr, unsigned long len, unsigned long pgoff)
> +{
[snip]

> +	find_vma_prepare(mm, addr, &prev, &rb_link, &rb_parent);
> +	new_vma = vma_merge(mm, prev, rb_parent, addr, addr + len,
> +			vma->vm_flags, vma->vm_file, pgoff);
[snip]
> +}
>
>  static unsigned long move_vma(struct vm_area_struct *vma,
>  {
[snip]
> +	new_vma = copy_vma(vma, new_addr, new_len, new_pgoff);
> +	if (!new_vma)
> +		return -ENOMEM;
[snip]
> +	moved_len = move_page_tables(vma, new_addr, old_addr, old_len);
> +	if (moved_len < old_len) {
> +		/*
> +		 * On error, move entries back from new area to old,
> +		 * which will succeed since page tables still there,
> +		 * and then proceed to unmap new area instead of old.
> +		 *
> +		 * Subtle point from Rajesh Venkatasubramanian: before
> +		 * moving file-based ptes, move new_vma before old vma
> +		 * in the i_mmap or i_mmap_shared list, so when racing
> +		 * against vmtruncate we cannot propagate pages to be
> +		 * truncated back from new_vma into just cleaned old.
> +		 */
> +		vma_relink_file(vma, new_vma);
> +		move_page_tables(new_vma, old_addr, new_addr, moved_len);
> +		vma = new_vma;
> +		old_len = new_len;
> +		old_addr = new_addr;
> +		new_addr = -ENOMEM;
> +	}

IF prio_tree gets merged and IF we plan to go by this vma ordering
solution for fixing vmtruncate vs. mremap race, then the vma_merge
in the copy_vma can bite us. The prio_tree only keeps the vmas that
_exactly_ map the same file pages in a list. If two vmas map different
set of file pages, then the ordering between them can change under
us if we drop i_shared_sem.

If we decide to go with the ordering solution, then my plan is to
setup an identical new_vma (that exactly maps same file pages as vma)
at new_addr and move the page tables. If the move fails, then use
vma_relink_file. If the move is successful, then we can do vma_merge.
I think we can think about these changes later. No hurry at this point.

Thanks,
Rajesh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/