From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07FC9C433EF for ; Mon, 7 Mar 2022 07:07:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 765298D0002; Mon, 7 Mar 2022 02:07:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 714E38D0001; Mon, 7 Mar 2022 02:07:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6045E8D0002; Mon, 7 Mar 2022 02:07:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 51E118D0001 for ; Mon, 7 Mar 2022 02:07:20 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F23A782F3110 for ; Mon, 7 Mar 2022 07:07:19 +0000 (UTC) X-FDA: 79216709040.28.7544D22 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf09.hostedemail.com (Postfix) with ESMTP id B1130140004 for ; Mon, 7 Mar 2022 07:07:18 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KBqGn0dQZzBrc6; Mon, 7 Mar 2022 15:05:21 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Mar 2022 15:07:13 +0800 Subject: Re: [PATCH 4/4] mm/memory-failure.c: fix potential VM_BUG_ON_PAGE in split_huge_page_to_list To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= CC: "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" References: <20220228140245.24552-1-linmiaohe@huawei.com> <20220228140245.24552-5-linmiaohe@huawei.com> <20220304082804.GC3778609@hori.linux.bs1.fc.nec.co.jp> From: Miaohe Lin Message-ID: <2311bee4-cc11-93fc-6992-6c327a150e3d@huawei.com> Date: Mon, 7 Mar 2022 15:07:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20220304082804.GC3778609@hori.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset="utf-8" Content-Language: en-US X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B1130140004 X-Stat-Signature: efr684m3n948akr5rr1cg68xb97kdd1w Authentication-Results: imf09.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf09.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com X-HE-Tag: 1646636838-753633 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022/3/4 16:28, HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3 =E7=9B=B4=E4=B9=9F)= wrote: > 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, th= e >> VM_BUG_ON_PAGE will be triggered in split_huge_page_to_list(). Also th= e >> non-lru compound movable pages could be taken for transhuge pages. Ski= p >> these pages by checking PageLRU because huge zero page isn't lru page = as >> non-lru compound movable pages. >=20 > It seems that memory_failure() also fails at get_any_page() with "hwpoi= son: > unhandlable page" message. >=20 > [16478.203474] page:00000000b6acdbd1 refcount:1 mapcount:0 mapping:00= 00000000000000 index:0x0 pfn:0x1810b4 > [16478.206612] flags: 0x57ffffc0801000(reserved|hwpoison|node=3D1|zon= e=3D2|lastcpupid=3D0x1fffff) > [16478.209411] raw: 0057ffffc0801000 fffff11bc6042d08 fffff11bc6042d0= 8 0000000000000000 > [16478.211921] raw: 0000000000000000 0000000000000000 00000001fffffff= f 0000000000000000 > [16478.214473] page dumped because: hwpoison: unhandlable page > [16478.216386] Memory failure: 0x1810b4: recovery action for unknown = page: Ignored >=20 > We can't handle errors on huge (or normal) zero page, so the current Sorry for confusing commit log again. I should have a coffee before I mak= e this patch. Huge or normal zero page will fail at get_any_page because they're neithe= r HWPoisonHandlable nor PageHuge. > behavior seems to me more suitable than "unsplit thp". >=20 > Or if you have some producer to reach the following path with huge zero > page, could you share it? >=20 What I mean is that non-lru movable compound page can reach here unexpect= ed because __PageMovable(page) is handleable now. So get_any_page could succeed to grab the page refcnt.= And since it's compound page, it will go through the split_huge_page_to_list because PageTransHuge chec= ks PageHead(page) which can also be true for compound page. But this type of pages is unexpected for split= _huge_page_to_list. Does this make sense for you? Thanks Naoya. > Thanks, > Naoya Horiguchi >=20 >> >> Signed-off-by: Miaohe Lin >> --- >> 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= ) >> } >> =20 >> 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 =3D -EBUSY; >> + goto unlock_mutex; >> + } >> /* >> * The flag must be set after the refcount is bumped >> * otherwise it may race with THP split. >> --=20 >> 2.23.0