[lkml]   [2011]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subject[patch 12/29] mm: fix possible cause of a page_mapped BUG
    2.6.37-stable review patch.  If anyone has any objections, please let us know.


    From: Hugh Dickins <>

    commit a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7 upstream.

    Robert Swiecki reported a BUG_ON(page_mapped) from a fuzzer, punching
    a hole with madvise(,, MADV_REMOVE). That path is under mutex, and
    cannot be explained by lack of serialization in unmap_mapping_range().

    Reviewing the code, I found one place where vm_truncate_count handling
    should have been updated, when I switched at the last minute from one
    way of managing the restart_addr to another: mremap move changes the
    virtual addresses, so it ought to adjust the restart_addr.

    But rather than exporting the notion of restart_addr from memory.c, or
    converting to restart_pgoff throughout, simply reset vm_truncate_count
    to 0 to force a rescan if mremap move races with preempted truncation.

    We have no confirmation that this fixes Robert's BUG,
    but it is a fix that's worth making anyway.

    Signed-off-by: Hugh Dickins <>
    Signed-off-by: Linus Torvalds <>
    Cc: Kerin Millar <>
    Signed-off-by: Greg Kroah-Hartman <>

    mm/mremap.c | 4 +---
    1 file changed, 1 insertion(+), 3 deletions(-)

    --- a/mm/mremap.c
    +++ b/mm/mremap.c
    @@ -91,9 +91,7 @@ static void move_ptes(struct vm_area_str
    mapping = vma->vm_file->f_mapping;
    - if (new_vma->vm_truncate_count &&
    - new_vma->vm_truncate_count != vma->vm_truncate_count)
    - new_vma->vm_truncate_count = 0;
    + new_vma->vm_truncate_count = 0;


     \ /
      Last update: 2011-03-11 01:05    [W:0.022 / U:74.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site