linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Xu Yu <xuyu@linux.alibaba.com>
Cc: <akpm@linux-foundation.org>, <naoya.horiguchi@nec.com>,
	<shy828301@gmail.com>, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH 1/2] Revert "mm/memory-failure.c: skip huge_zero_page in memory_failure()"
Date: Thu, 28 Apr 2022 10:23:05 +0800	[thread overview]
Message-ID: <480640f2-8bee-692c-2beb-24d36774d5b1@huawei.com> (raw)
In-Reply-To: <872cefb182ba1dd686b0e7db1e6b2ebe5a4fff87.1651039624.git.xuyu@linux.alibaba.com>

On 2022/4/27 14:10, Xu Yu wrote:
> This reverts commit d173d5417fb67411e623d394aab986d847e47dad.
> 
> The commit d173d5417fb6 ("mm/memory-failure.c: skip huge_zero_page in
> memory_failure()") explicitly skips huge_zero_page in memory_failure(),
> in order to avoid triggering VM_BUG_ON_PAGE on huge_zero_page in
> split_huge_page_to_list().
> 
> This works, but Yang Shi thinks that,
> 
>     Raising BUG is overkilling for splitting huge_zero_page. The
>     huge_zero_page can't be met from normal paths other than memory
>     failure, but memory failure is a valid caller. So I tend to replace
>     the BUG to WARN + returning -EBUSY. If we don't care about the
>     reason code in memory failure, we don't have to touch memory
>     failure.
> 
> And for the issue that huge_zero_page will be set PG_has_hwpoisoned,
> Yang Shi comments that,
> 
>     The anonymous page fault doesn't check if the page is poisoned or
>     not since it typically gets a fresh allocated page and assumes the
>     poisoned page (isolated successfully) can't be reallocated again.
>     But huge zero page and base zero page are reused every time. So no
>     matter what fix we pick, the issue is always there.
> 
> Finally, Yang, David, Anshuman and Naoya all agree to fix the bug, i.e.,
> to split huge_zero_page, in split_huge_page_to_list().
> 
> This reverts the commit d173d5417fb6 ("mm/memory-failure.c: skip
> huge_zero_page in memory_failure()"), and the original bug will be fixed
> by the next patch.
> 
> Suggested-by: Yang Shi <shy828301@gmail.com>
> Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
> Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>

LGTM. Thanks!

Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>

> ---
>  mm/memory-failure.c | 13 -------------
>  1 file changed, 13 deletions(-)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 27760c19bad7..2020944398c9 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1860,19 +1860,6 @@ int memory_failure(unsigned long pfn, int flags)
>  	}
>  
>  	if (PageTransHuge(hpage)) {
> -		/*
> -		 * Bail out before SetPageHasHWPoisoned() if hpage is
> -		 * huge_zero_page, although PG_has_hwpoisoned is not
> -		 * checked in set_huge_zero_page().
> -		 *
> -		 * TODO: Handle memory failure of huge_zero_page thoroughly.
> -		 */
> -		if (is_huge_zero_page(hpage)) {
> -			action_result(pfn, MF_MSG_UNSPLIT_THP, MF_IGNORED);
> -			res = -EBUSY;
> -			goto unlock_mutex;
> -		}
> -
>  		/*
>  		 * The flag must be set after the refcount is bumped
>  		 * otherwise it may race with THP split.
> 



  parent reply	other threads:[~2022-04-28  2:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27  6:10 [PATCH 0/2] mm/memory-failure: rework fix on huge_zero_page splitting Xu Yu
2022-04-27  6:10 ` [PATCH 1/2] Revert "mm/memory-failure.c: skip huge_zero_page in memory_failure()" Xu Yu
2022-04-27 21:13   ` Yang Shi
2022-04-28  2:23   ` Miaohe Lin [this message]
2022-04-27  6:10 ` [PATCH 2/2] mm/huge_memory: do not overkill when splitting huge_zero_page Xu Yu
2022-04-27  7:12   ` HORIGUCHI NAOYA(堀口 直也)
2022-04-27  7:37     ` Yu Xu
2022-04-27 19:00     ` Andrew Morton
2022-04-27  9:01   ` kernel test robot
2022-04-27  9:48     ` Yu Xu
2022-04-27  9:36   ` kernel test robot
2022-04-27  9:44   ` [PATCH 2/2 RESEND] " Xu Yu
2022-04-27 21:15     ` Yang Shi
2022-04-28  2:25     ` Miaohe Lin
2022-04-28 16:04     ` David Hildenbrand
2022-04-28 17:18       ` Yang Shi
2022-04-28  1:59   ` [PATCH 2/2] " kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=480640f2-8bee-692c-2beb-24d36774d5b1@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=shy828301@gmail.com \
    --cc=xuyu@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).