lkml.org 
[lkml]   [2015]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 3.12 039/123] mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault
    Date
    From: Mel Gorman <mgorman@techsingularity.net>

    3.12-stable review patch. If anyone has any objections, please let me know.

    ===============

    commit 2f84a8990ebbe235c59716896e017c6b2ca1200f upstream.

    SunDong reported the following on

    https://bugzilla.kernel.org/show_bug.cgi?id=103841

    I think I find a linux bug, I have the test cases is constructed. I
    can stable recurring problems in fedora22(4.0.4) kernel version,
    arch for x86_64. I construct transparent huge page, when the parent
    and child process with MAP_SHARE, MAP_PRIVATE way to access the same
    huge page area, it has the opportunity to lead to huge page copy on
    write failure, and then it will munmap the child corresponding mmap
    area, but then the child mmap area with VM_MAYSHARE attributes, child
    process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
    functions (vma - > vm_flags & VM_MAYSHARE).

    There were a number of problems with the report (e.g. it's hugetlbfs that
    triggers this, not transparent huge pages) but it was fundamentally
    correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
    looks like this

    vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
    next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
    prot 8000000000000027 anon_vma (null) vm_ops ffffffff8182a7a0
    pgoff 0 file ffff88106bdb9800 private_data (null)
    flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
    ------------
    kernel BUG at mm/hugetlb.c:462!
    SMP
    Modules linked in: xt_pkttype xt_LOG xt_limit [..]
    CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
    Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
    set_vma_resv_flags+0x2d/0x30

    The VM_BUG_ON is correct because private and shared mappings have
    different reservation accounting but the warning clearly shows that the
    VMA is shared.

    When a private COW fails to allocate a new page then only the process
    that created the VMA gets the page -- all the children unmap the page.
    If the children access that data in the future then they get killed.

    The problem is that the same file is mapped shared and private. During
    the COW, the allocation fails, the VMAs are traversed to unmap the other
    private pages but a shared VMA is found and the bug is triggered. This
    patch identifies such VMAs and skips them.

    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
    Reported-by: SunDong <sund_sky@126.com>
    Reviewed-by: Michal Hocko <mhocko@suse.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: David Rientjes <rientjes@google.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    ---
    mm/hugetlb.c | 8 ++++++++
    1 file changed, 8 insertions(+)

    diff --git a/mm/hugetlb.c b/mm/hugetlb.c
    index c91c347bb3ea..a3a9676c65cf 100644
    --- a/mm/hugetlb.c
    +++ b/mm/hugetlb.c
    @@ -2605,6 +2605,14 @@ static int unmap_ref_private(struct mm_struct *mm, struct vm_area_struct *vma,
    continue;

    /*
    + * Shared VMAs have their own reserves and do not affect
    + * MAP_PRIVATE accounting but it is possible that a shared
    + * VMA is using the same page so check and skip such VMAs.
    + */
    + if (iter_vma->vm_flags & VM_MAYSHARE)
    + continue;
    +
    + /*
    * Unmap the page from other VMAs without their own reserves.
    * They get marked to be SIGKILLed if they fault in these
    * areas. This is because a future no-page fault on this VMA
    --
    2.6.2


    \
     
     \ /
      Last update: 2015-10-28 15:41    [W:7.250 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site