• Andrew Morton's avatar
    [PATCH] rmap 11 mremap moves · 70b671f8
    Andrew Morton authored
    From: Hugh Dickins <hugh@veritas.com>
    
    A weakness of the anonmm scheme is its difficulty in tracking pages shared
    between two or more mms (one being an ancestor of the other), when mremap has
    been used to move a range of pages in one of those mms.  mremap move is not
    very common anyway, and it's more often used on a page range exclusive to the
    mm; but uncommon though it may be, we must not allow unlocked pages to become
    unswappable.
    
    This patch follows Linus' suggestion, simply to take a private copy of the
    page in such a case: early C-O-W.  My previous implementation was daft with
    respect to pages currently on swap: it insisted on swapping them in to copy
    them.  No need for that: just take the copy when a page is brought in from
    swap, and its intended address is found to clash with what rmap has already
    noted.
    
    If do_swap_page has to make this copy in the mremap moved case (simply a call
    to do_wp_page), might as well do so also in the case when it's a write access
    but the page not exclusive, it's always seemed a little odd that swapin needed
    a second fault for that.  A bug even: get_user_pages force imagines that a
    single call to handle_mm_fault must break C-O-W.  Another bugfix: swapoff's
    unuse_process didn't check is_vm_hugetlb_page.
    
    Andrea's anon_vma has no such problem with mremap moved pages, handling them
    with elegant use of vm_pgoff - though at some cost to vma merging.  How
    important is it to handle them efficiently?  For now there's a msg
    printk(KERN_WARNING "%s: mremap moved %d cows\n", current->comm, cows);
    70b671f8
rmap.c 22.5 KB