Question: why hold source mm->mmap_sem write sem in dup_mmap()?

Question: why hold source mm->mmap_sem write sem in dup_mmap()?

[Chen, Kenneth W]

In the call chain of copy_page_range coming from do_fork(), dup_mmap holds
write semaphore on the oldmm.  I don't see copy_page_range() or dup_mmap
itself alter the source (oldmm)'s address space, what is the reason to hold
write semaphore on the source mm?  Won't a down_read(&oldmm->mmap_sem) be
sufficient?  Did I miss something there?


do_fork
  copy_process
    copy_mm
      dup_mm
        dup_mmap
          copy_page_range

static inline int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm)
{
        ...
        down_write(&oldmm->mmap_sem);
        flush_cache_mm(oldmm);
        down_write_nested(&mm->mmap_sem, SINGLE_DEPTH_NESTING);
        ...
        for (mpnt = oldmm->mmap; mpnt; mpnt = mpnt->vm_next) {
                ...
                retval = copy_page_range(mm, oldmm, mpnt);
        }
        ...

        up_write(&mm->mmap_sem);
        flush_tlb_mm(oldmm);
        up_write(&oldmm->mmap_sem);
}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Question: why hold source mm->mmap_sem write sem in dup_mmap()?

[Hugh Dickins]

On Fri, 29 Sep 2006, Chen, Kenneth W wrote:
> In the call chain of copy_page_range coming from do_fork(), dup_mmap holds
> write semaphore on the oldmm.  I don't see copy_page_range() or dup_mmap
> itself alter the source (oldmm)'s address space, what is the reason to hold
> write semaphore on the source mm?  Won't a down_read(&oldmm->mmap_sem) be
> sufficient?  Did I miss something there?

Good question, I think you're right: it's just a leftover from when 2.4.3
changed mmap_sem to an rwsem, and most down()s became down_write()s, with
the advantageously-concurrent faulting ones changed to down_read()s.

(For a while it was thought to hold rss steady, so copy_page_range didn't
bother to increment: but that only applied to faulting in, it was no
protection against vmscan swapping out, and so had to be fixed later.)

Hold on, there is one thing it's guarding against: expand_stack(), which
may extend stack vma with only down_read of mmap_sem (+ anon_vma_lock),
and in the downward case needs to adjust vm_start and vm_pgoff together.
Though I doubt that's conscious, nor a good reason to keep the down_write.

And I notice that total_vm and the vm_stat_account fields have been
copied over from oldmm to new mm, without any hold on mmap_sem at all:
not very serious, but we ought to fix it.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>