• Mel Gorman's avatar
    mm: numa: recheck for transhuge pages under lock during protection changes · 1ad9f620
    Mel Gorman authored
    Sasha reported the following bug using trinity
    
      kernel BUG at mm/mprotect.c:149!
      invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 20 PID: 26219 Comm: trinity-c216 Tainted: G        W    3.14.0-rc5-next-20140305-sasha-00011-ge06f5f3-dirty #105
      task: ffff8800b6c80000 ti: ffff880228436000 task.ti: ffff880228436000
      RIP: change_protection_range+0x3b3/0x500
      Call Trace:
        change_protection+0x25/0x30
        change_prot_numa+0x1b/0x30
        task_numa_work+0x279/0x360
        task_work_run+0xae/0xf0
        do_notify_resume+0x8e/0xe0
        retint_signal+0x4d/0x92
    
    The VM_BUG_ON was added in -mm by the patch "mm,numa: reorganize
    change_pmd_range".  The race existed without the patch but was just
    harder to hit.
    
    The problem is that a transhuge check is made without holding the PTL.
    It's possible at the time of the check that a parallel fault clears the
    pmd and inserts a new one which then triggers the VM_BUG_ON check.  This
    patch removes the VM_BUG_ON but fixes the race by rechecking transhuge
    under the PTL when marking page tables for NUMA hinting and bailing if a
    race occurred.  It is not a problem for calls to mprotect() as they hold
    mmap_sem for write.
    Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
    Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
    Reviewed-by: default avatarRik van Riel <riel@redhat.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    1ad9f620
mprotect.c 10.5 KB