lkml.org 
[lkml]   [2004]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] anobjrmap 7/6 mremap moves

> +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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.118 / U:1.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site