The patch titled
Subject: mm/hugetlb: use get_page_unless_zero() in hugetlb_fault()
has been added to the -mm tree. Its filename is
mm-hugetlb-use-get_page_unless_zero-in-hugetlb_fault.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-use-get_page_unless_zero-in-hugetlb_fault.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-use-get_page_unless_zero-in-hugetlb_fault.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Naoya Horiguchi <[email protected]>
Subject: mm/hugetlb: use get_page_unless_zero() in hugetlb_fault()
After fixing locking in follow_page(FOLL_GET) for hugepages, I start to
observe the BUG of "get_page() on refcount 0 page" in hugetlb_fault() in
the same test.
I'm not exactly sure about how this race is triggered, but hugetlb_fault()
calls pte_page() and get_page() outside page table lock, so it's not safe.
This patch checks the refcount of the gotten page, and aborts the page
fault if the refcount is 0, expecting to retry.
Signed-off-by: Naoya Horiguchi <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: <[email protected]> [3.12+]
Signed-off-by: Andrew Morton <[email protected]>
---
mm/hugetlb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff -puN mm/hugetlb.c~mm-hugetlb-use-get_page_unless_zero-in-hugetlb_fault
mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-use-get_page_unless_zero-in-hugetlb_fault
+++ a/mm/hugetlb.c
@@ -3192,7 +3192,8 @@ int hugetlb_fault(struct mm_struct *mm,
* so no worry about deadlock.
*/
page = pte_page(entry);
- get_page(page);
+ if (!get_page_unless_zero(page))
+ goto out_put_pagecache;
if (page != pagecache_page)
lock_page(page);
@@ -3218,15 +3219,14 @@ int hugetlb_fault(struct mm_struct *mm,
out_ptl:
spin_unlock(ptl);
-
+ if (page != pagecache_page)
+ unlock_page(page);
+ put_page(page);
+out_put_pagecache:
if (pagecache_page) {
unlock_page(pagecache_page);
put_page(pagecache_page);
}
- if (page != pagecache_page)
- unlock_page(page);
- put_page(page);
-
out_mutex:
mutex_unlock(&htlb_fault_mutex_table[hash]);
return ret;
_
Patches currently in -mm which might be from [email protected] are
origin.patch
mm-memcontrol-rewrite-charge-api-fix-hugetlb-charging.patch
mm-memcontrol-use-page-lists-for-uncharge-batching-fix-hugetlb-page-lru.patch
mm-update-the-description-for-madvise_remove.patch
mm-hwpoison-injectc-remove-unnecessary-null-test-before-debugfs_remove_recursive.patch
hwpoison-fix-race-with-changing-page-during-offlining-v2.patch
mm-hugetlb-generalize-writes-to-nr_hugepages.patch
mm-hugetlb-generalize-writes-to-nr_hugepages-fix.patch
mm-hugetlb-remove-hugetlb_zero-and-hugetlb_infinity.patch
mm-fix-potential-infinite-loop-in-dissolve_free_huge_pages.patch
mm-fix-potential-infinite-loop-in-dissolve_free_huge_pages-fix.patch
mm-softdirty-respect-vm_softdirty-in-pte-holes.patch
mm-hugetlb-take-refcount-under-page-table-lock-in-follow_huge_pmd.patch
mm-hugetlb-use-get_page_unless_zero-in-hugetlb_fault.patch
mm-hugetlb-add-migration-entry-check-in-hugetlb_change_protection.patch
mm-introduce-do_shared_fault-and-drop-do_fault-fix-fix.patch
do_shared_fault-check-that-mmap_sem-is-held.patch
linux-next.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
