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 7D17BC4321E for ; Tue, 8 Mar 2022 12:36:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FEFC8D0002; Tue, 8 Mar 2022 07:36:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AE7C8D0001; Tue, 8 Mar 2022 07:36:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDEF68D0002; Tue, 8 Mar 2022 07:36:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id DB3D68D0001 for ; Tue, 8 Mar 2022 07:36:46 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AA26D24812 for ; Tue, 8 Mar 2022 12:36:46 +0000 (UTC) X-FDA: 79221168012.15.D6C7E21 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf28.hostedemail.com (Postfix) with ESMTP id 3E516C000C for ; Tue, 8 Mar 2022 12:36:44 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KCZY243NkzdZwv; Tue, 8 Mar 2022 20:35:18 +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; Tue, 8 Mar 2022 20:36:39 +0800 Subject: Re: [PATCH 4/4] mm/memory-failure.c: fix potential VM_BUG_ON_PAGE in split_huge_page_to_list To: Yang Shi CC: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , "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> <2311bee4-cc11-93fc-6992-6c327a150e3d@huawei.com> From: Miaohe Lin Message-ID: Date: Tue, 8 Mar 2022 20:36:39 +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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 3E516C000C X-Stat-Signature: tgwtget6oqnsrcq7hgpo1ya457uztr9y X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspamd-Server: rspam07 X-HE-Tag: 1646743004-752404 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/8 3:53, Yang Shi wrote: > On Sun, Mar 6, 2022 at 11:07 PM Miaohe Lin wrote: >> >> On 2022/3/4 16:28, HORIGUCHI NAOYA(堀口 直也) 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, 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 >> >> Sorry for confusing commit log again. I should have a coffee before I make this patch. >> Huge or normal zero page will fail at get_any_page because they're neither HWPoisonHandlable >> nor PageHuge. >> >>> 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? >>> >> >> What I mean is that non-lru movable compound page can reach here unexpected 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 checks PageHead(page) which can also >> be true for compound page. But this type of pages is unexpected for split_huge_page_to_list. > > Can we really handle non-LRU movable pages in memory failure > (uncorrectable errors)? Typically they are balloon, zsmalloc, etc. > Assuming we run into a base (4K) non-LRU movable page, we could reach > as far as identify_page_state(), it should not fall into any category > except me_unknown. So it seems we could just simply make it > unhandlable. There is the comment from memory_failure: /* * We ignore non-LRU pages for good reasons. * - PG_locked is only well defined for LRU pages and a few others * - to avoid races with __SetPageLocked() * - to avoid races with __SetPageSlab*() (and more non-atomic ops) * The check (unnecessarily) ignores LRU pages being isolated and * walked by the page reclaim code, however that's not a big loss. */ So we could not handle non-LRU movable pages. What do you mean is something like below? diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 5444a8ef4867..d80dbe0f20b6 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1784,6 +1784,13 @@ int memory_failure(unsigned long pfn, int flags) } } + if (__PageMovable(hpage)) { + put_page(p); + action_result(pfn, MF_MSG_MOVALBE_PAGE, MF_IGNORED); + res = -EBUSY; + goto unlock_mutex; + } + if (PageTransHuge(hpage)) { /* * The flag must be set after the refcount is bumped i.e. Simply make non-LRU movable pages unhandlable ? > > But it should be handlable for soft-offline since it could be migrated. > Yes, non-LRU movable pages can be simply migrated. Many thanks. > >> Does this make sense for you? Thanks Naoya. >> >>> Thanks, >>> Naoya Horiguchi >>> >>>> >>>> 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) >>>> } >>>> >>>> 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 >> >> > . >