2020-06-24 15:04:55

by Naoya Horiguchi

[permalink] [raw]
Subject: [PATCH v3 01/15] mm,hwpoison: cleanup unused PageHuge() check

From: Naoya Horiguchi <[email protected]>

Drop the PageHuge check, which is dead code since memory_failure() forks
into memory_failure_hugetlb() for hugetlb pages.

memory_failure() and memory_failure_hugetlb() shares some functions like
hwpoison_user_mappings() and identify_page_state(), so they should properly
handle 4kB page, thp, and hugetlb.

Signed-off-by: Naoya Horiguchi <[email protected]>
Signed-off-by: Oscar Salvador <[email protected]>
---
changelog v2 -> v3:
- add description about shared logic b/w hugetlb and non-hugetlb path.
---
mm/memory-failure.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git v5.8-rc1-mmots-2020-06-20-21-44/mm/memory-failure.c v5.8-rc1-mmots-2020-06-20-21-44_patched/mm/memory-failure.c
index 47b8ccb1fb9b..e5d0c14c2332 100644
--- v5.8-rc1-mmots-2020-06-20-21-44/mm/memory-failure.c
+++ v5.8-rc1-mmots-2020-06-20-21-44_patched/mm/memory-failure.c
@@ -1382,10 +1382,7 @@ int memory_failure(unsigned long pfn, int flags)
* page_remove_rmap() in try_to_unmap_one(). So to determine page status
* correctly, we save a copy of the page flags at this time.
*/
- if (PageHuge(p))
- page_flags = hpage->flags;
- else
- page_flags = p->flags;
+ page_flags = p->flags;

/*
* unpoison always clear PG_hwpoison inside page lock
--
2.17.1


2020-06-30 23:33:42

by Mike Kravetz

[permalink] [raw]
Subject: Re: [PATCH v3 01/15] mm,hwpoison: cleanup unused PageHuge() check

On 6/24/20 8:01 AM, [email protected] wrote:
> From: Naoya Horiguchi <[email protected]>
>
> Drop the PageHuge check, which is dead code since memory_failure() forks
> into memory_failure_hugetlb() for hugetlb pages.
>
> memory_failure() and memory_failure_hugetlb() shares some functions like
> hwpoison_user_mappings() and identify_page_state(), so they should properly
> handle 4kB page, thp, and hugetlb.
>
> Signed-off-by: Naoya Horiguchi <[email protected]>
> Signed-off-by: Oscar Salvador <[email protected]>

Reviewed-by: Mike Kravetz <[email protected]>
--
Mike Kravetz