lkml.org 
[lkml]   [2022]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/4] mm/memory-failure.c: fix race with changing page compound again
Date
On Mon, Feb 28, 2022 at 10:02:42PM +0800, Miaohe Lin wrote:
> There is a race window where we got the compound_head, the hugetlb page
> could be freed to buddy, or even changed to another compound page just
> before we try to get hwpoison page. If this happens, just bail out.

I think that when some hugetlb page is about to change into other type/size
of compound page, it has to go through buddy allocator because hugetlb pages
are maintained in separate memory allocator and they never change into other
normal state directly. memory_failure_hugetlb() takes refcount before
lock_page(), so the hugetlb page seems not change between get_hwpoison_page()
and lock_page(). So it this new check really necessary?

Thanks,
Naoya Horiguchi

>
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---
> mm/memory-failure.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 5444a8ef4867..0d7c58340a98 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1534,6 +1534,17 @@ static int memory_failure_hugetlb(unsigned long pfn, int flags)
> }
>
> lock_page(head);
> +
> + /**
> + * The page could have changed compound pages due to race window.
> + * If this happens just bail out.
> + */
> + if (!PageHuge(p) || compound_head(p) != head) {
> + action_result(pfn, MF_MSG_DIFFERENT_COMPOUND, MF_IGNORED);
> + res = -EBUSY;
> + goto out;
> + }
> +
> page_flags = head->flags;
>
> if (hwpoison_filter(p)) {
> --
> 2.23.0
\
 
 \ /
  Last update: 2022-03-04 09:27    [W:1.364 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site