On 6/3/21 4:36 PM, Naoya Horiguchi wrote:
> From: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>
>
> When hugetlb page fault (under overcommitting situation) and
> memory_failure() race, VM_BUG_ON_PAGE() is triggered by the following race:
>
> CPU0: CPU1:
>
> gather_surplus_pages()
> page = alloc_surplus_huge_page()
> memory_failure_hugetlb()
> get_hwpoison_page(page)
> __get_hwpoison_page(page)
> get_page_unless_zero(page)
> zero = put_page_testzero(page)
> VM_BUG_ON_PAGE(!zero, page)
> enqueue_huge_page(h, page)
> put_page(page)
>
> __get_hwpoison_page() only checks the page refcount before taking an
> additional one for memory error handling, which is not enough because
> there's a time window where compound pages have non-zero refcount during
> hugetlb page initialization.
>
> So make __get_hwpoison_page() check page status a bit more for hugetlb
> pages with get_hwpoison_huge_page(). Checking hugetlb-specific flags
> under hugetlb_lock makes sure that the hugetlb page is not transitive.
> It's notable that another new function, HWPoisonHandlable(), is helpful
> to prevent a race against other transitive page states (like a generic
> compound page just before PageHuge becomes true).
Thanks!
I believe this is good enough to prevent the race. Since access to the
page is not synchronized in any way, it would still be "theoretically
possible" to race. For example,
CPU0: CPU1:
HWPoisonHandlable true
page freed to buddy
page allocated from buddy
page added to hugetlb pool
alloc_surplus_huge_page
But, this is very Very VERY unlikely to ever happen.
>
> Fixes: ead07f6a867b ("mm/memory-failure: introduce get_hwpoison_page() for consistent refcount handling")
> Signed-off-by: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>
> Reported-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx # 5.12+
> ---
> ChangeLog v6:
> - defined HWPoisonHandlable(),
> - updated comment and patch description.
> ---
> include/linux/hugetlb.h | 6 ++++++
> mm/hugetlb.c | 15 +++++++++++++++
> mm/memory-failure.c | 29 +++++++++++++++++++++++++++--
> 3 files changed, 48 insertions(+), 2 deletions(-)
Acked-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
--
Mike Kravetz
