[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c542543-0965-ef60-4627-1a4116077a5b@huawei.com>
Date: Tue, 2 Aug 2022 10:00:50 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Linux-MM <linux-mm@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
Muchun Song <songmuchun@...edance.com>
Subject: [bug report] mm, hwpoison: memory_failure races with
alloc_fresh_huge_page/free_huge_page
Hi all:
When I investigate the mm/memory-failure.c code again, I found there's a possible race window
between memory_failure and alloc_fresh_huge_page/free_huge_page. Thank about the below scene:
CPU 1 CPU 2
alloc_fresh_huge_page -- page refcnt > 0 memory_failure
prep_new_huge_page get_huge_page_for_hwpoison
!PageHeadHuge -- so 2(not a hugepage) is returned
hugetlb_vmemmap_optimize -- subpages is read-only
set_compound_page_dtor -- PageHuge is true now, but too late!!!
TestSetPageHWPoison(p)
-- We might write to read-only subpages here!!!
Another similar scene:
CPU 1 CPU 2
free_huge_page -- page refcnt == 0 and not PageHuge memory_failure
get_huge_page_for_hwpoison
!PageHeadHuge -- so 2(not a hugepage) is returned
TestSetPageHWPoison(p)
-- We might write to read-only subpages here!!!
hugetlb_vmemmap_restore -- subpages can be written to now, but too late!!!
I think the above scenes are possible. But I can't found a stable solution to fix it. Any suggestions?
Or is it not worth to fix it as it's too rare? Or am I miss something?
Any response would be appreciated!
Thanks!
Powered by blists - more mailing lists