Doug / smarc-fsl-linux-kernel

Download as
Browse Code ยป

Commit 5dbe0af47f8a8f968bac2991c3ec974c6e3eaabc

Authored by Hugh Dickins
Committed by Linus Torvalds
1 parent 826267cf1e
Exists in master and in 7 other branches imx_3.0.35_4.1.0, imx_3.10.17_1.0.1_ga, imx_3.10.53_1.1.0_ga, imx_3.14.28_1.0.0_ga, smarc-imx_3.10.53_1.1.0_ga, smarc-imx_3.14.28_1.0.0_ga, smarc-l5.0.0_1.0.0-ga

mm: fix kernel BUG at mm/rmap.c:1017! 

I've hit the "address >= vma->vm_end" check in do_page_add_anon_rmap()
just once.  The stack showed khugepaged allocation trying to compact
pages: the call to page_add_anon_rmap() coming from remove_migration_pte().

That path holds anon_vma lock, but does not hold mmap_sem: it can
therefore race with a split_vma(), and in commit 5f70b962ccc2 "mmap:
avoid unnecessary anon_vma lock" we just took away the anon_vma lock
protection when adjusting vma->vm_end.

I don't think that particular BUG_ON ever caught anything interesting,
so better replace it by a comment, than reinstate the anon_vma locking.

Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Showing 1 changed file with 2 additions and 2 deletions Side-by-side Diff

... ... @@ -1014,7 +1014,7 @@
1014 1014 return;
1015 1015  
1016 1016 VM_BUG_ON(!PageLocked(page));
1017   - VM_BUG_ON(address < vma->vm_start || address >= vma->vm_end);
  1017 + /* address might be in next vma when migration races vma_adjust */
1018 1018 if (first)
1019 1019 __page_set_anon_rmap(page, vma, address, exclusive);
1020 1020 else
... ... @@ -1709,7 +1709,7 @@
1709 1709  
1710 1710 BUG_ON(!PageLocked(page));
1711 1711 BUG_ON(!anon_vma);
1712   - BUG_ON(address < vma->vm_start || address >= vma->vm_end);
  1712 + /* address might be in next vma when migration races vma_adjust */
1713 1713 first = atomic_inc_and_test(&page->_mapcount);
1714 1714 if (first)
1715 1715 __hugepage_set_anon_rmap(page, vma, address, 0);