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.
>
next prev 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).