mm/rmap.c: fix pgoff calculation to handle hugepage correctly
authorNaoya Horiguchi <[email protected]>
Wed, 23 Jul 2014 21:00:01 +0000 (14:00 -0700)
committerLinus Torvalds <[email protected]>
Wed, 23 Jul 2014 22:10:54 +0000 (15:10 -0700)
commita0f7a756c2f7543585657cdeeefdfcc11b567293
tree05ddd356f6aa17f826a1923d8601dd3c78f7fbbc
parentaed8adb7688d5744cb484226820163af31d2499a
mm/rmap.c: fix pgoff calculation to handle hugepage correctly

I triggered VM_BUG_ON() in vma_address() when I tried to migrate an
anonymous hugepage with mbind() in the kernel v3.16-rc3.  This is
because pgoff's calculation in rmap_walk_anon() fails to consider
compound_order() only to have an incorrect value.

This patch introduces page_to_pgoff(), which gets the page's offset in
PAGE_CACHE_SIZE.

Kirill pointed out that page cache tree should natively handle
hugepages, and in order to make hugetlbfs fit it, page->index of
hugetlbfs page should be in PAGE_CACHE_SIZE.  This is beyond this patch,
but page_to_pgoff() contains the point to be fixed in a single function.

Signed-off-by: Naoya Horiguchi <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Hillf Danton <[email protected]>
Cc: Naoya Horiguchi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
include/linux/pagemap.h
mm/memory-failure.c
mm/rmap.c