linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>
To: Miaohe Lin <linmiaohe@huawei.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] mm/memory-failure.c: fix potential VM_BUG_ON_PAGE in split_huge_page_to_list
Date: Fri, 4 Mar 2022 08:28:05 +0000	[thread overview]
Message-ID: <20220304082804.GC3778609@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <20220228140245.24552-5-linmiaohe@huawei.com>

On Mon, Feb 28, 2022 at 10:02:45PM +0800, Miaohe Lin wrote:
> The huge zero page could reach here and if we ever try to split it, the
> VM_BUG_ON_PAGE will be triggered in split_huge_page_to_list(). Also the
> non-lru compound movable pages could be taken for transhuge pages. Skip
> these pages by checking PageLRU because huge zero page isn't lru page as
> non-lru compound movable pages.

It seems that memory_failure() also fails at get_any_page() with "hwpoison:
unhandlable page" message.

  [16478.203474] page:00000000b6acdbd1 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1810b4
  [16478.206612] flags: 0x57ffffc0801000(reserved|hwpoison|node=1|zone=2|lastcpupid=0x1fffff)
  [16478.209411] raw: 0057ffffc0801000 fffff11bc6042d08 fffff11bc6042d08 0000000000000000
  [16478.211921] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
  [16478.214473] page dumped because: hwpoison: unhandlable page
  [16478.216386] Memory failure: 0x1810b4: recovery action for unknown page: Ignored

We can't handle errors on huge (or normal) zero page, so the current
behavior seems to me more suitable than "unsplit thp".

Or if you have some producer to reach the following path with huge zero
page, could you share it?

Thanks,
Naoya Horiguchi

> 
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---
>  mm/memory-failure.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 23bfd809dc8c..ac6492e36978 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1792,6 +1792,20 @@ int memory_failure(unsigned long pfn, int flags)
>  	}
>  
>  	if (PageTransHuge(hpage)) {
> +		/*
> +		 * The non-lru compound movable pages could be taken for
> +		 * transhuge pages. Also huge zero page could reach here
> +		 * and if we ever try to split it, the VM_BUG_ON_PAGE will
> +		 * be triggered in split_huge_page_to_list(). Skip these
> +		 * pages by checking PageLRU because huge zero page isn't
> +		 * lru page as non-lru compound movable pages.
> +		 */
> +		if (!PageLRU(hpage)) {
> +			put_page(p);
> +			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.
> -- 
> 2.23.0

  reply	other threads:[~2022-03-04  8:28 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 14:02 [PATCH 0/4] A few fixup patches for memory failure Miaohe Lin
2022-02-28 14:02 ` [PATCH 1/4] mm/memory-failure.c: fix race with changing page compound again Miaohe Lin
2022-03-04  8:26   ` HORIGUCHI NAOYA(堀口 直也)
2022-03-04 19:32     ` Mike Kravetz
2022-03-07  3:44       ` Miaohe Lin
2022-03-07  7:01         ` HORIGUCHI NAOYA(堀口 直也)
2022-03-07 19:07           ` Mike Kravetz
2022-03-08  6:56             ` HORIGUCHI NAOYA(堀口 直也)
2022-03-08 11:28               ` Miaohe Lin
2022-02-28 14:02 ` [PATCH 2/4] mm/memory-failure.c: fix wrong user reference report Miaohe Lin
2022-03-04  8:27   ` HORIGUCHI NAOYA(堀口 直也)
2022-03-07 11:26     ` Miaohe Lin
2022-03-07 20:14       ` Yang Shi
2022-03-08 13:11         ` Miaohe Lin
2022-03-08 18:51           ` Yang Shi
2022-03-09  8:30             ` Miaohe Lin
2022-02-28 14:02 ` [PATCH 3/4] mm/memory-failure.c: avoid calling invalidate_inode_page() with unexpected pages Miaohe Lin
2022-02-28 14:02 ` [PATCH 4/4] mm/memory-failure.c: fix potential VM_BUG_ON_PAGE in split_huge_page_to_list Miaohe Lin
2022-03-04  8:28   ` HORIGUCHI NAOYA(堀口 直也) [this message]
2022-03-07  7:07     ` Miaohe Lin
2022-03-07 19:53       ` Yang Shi
2022-03-08 12:36         ` Miaohe Lin
2022-03-08 18:47           ` Yang Shi
2022-03-09  8:45             ` Miaohe Lin
2022-03-10 11:46             ` Miaohe Lin
2022-03-10 19:32               ` Yang Shi
2022-03-11  1:54                 ` Miaohe Lin

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=20220304082804.GC3778609@hori.linux.bs1.fc.nec.co.jp \
    --to=naoya.horiguchi@nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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).