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 59E27C3DA4A for ; Fri, 2 Aug 2024 08:02:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5C696B007B; Fri, 2 Aug 2024 04:02:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0D406B0083; Fri, 2 Aug 2024 04:02:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD3A86B0085; Fri, 2 Aug 2024 04:02:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9FA976B007B for ; Fri, 2 Aug 2024 04:02:44 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4DD2A1C4849 for ; Fri, 2 Aug 2024 08:02:44 +0000 (UTC) X-FDA: 82406563848.30.74F1464 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf11.hostedemail.com (Postfix) with ESMTP id 794C040022 for ; Fri, 2 Aug 2024 08:02:41 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722585705; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=69MB9OvkT6eyNYlTP/Oh9/2ClvtdRbS8b59jSZ5mS0E=; b=Rmn+3ToVa1ATpptPssOzRIiU6C1Bl7srAqaZk1yfUuL4VsEbbjfrZG5pOWkCAx2P/YuGtl 9yygOtfM0a/vLl2uCEtTGDSmZb62NAY8QvqkgGRRPlhrBRUDv+JyvtUJQVMbgLV+ZRJ0e9 jY/Hc6E9gewVLSsq6hIkP1nGj5QxtB8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722585705; a=rsa-sha256; cv=none; b=RC+EkN7H4Xd67qlTYVOgWXfo53cHlMQAi20szhr9z8Dofm3kj8rer4Qr61PuoPdb4ln1JT ABm6zE7mBGhbImrpzueACnUbGtiGkpM9Rb4vhc8GTBhXILcdsWmhRElwngYRSHR/KebgRm 0PfILIimcCbTvpLcVolg1v3OaFZ5OEQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4WZyr84ZlKzQnYs; Fri, 2 Aug 2024 15:58:16 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id B0420180AE5; Fri, 2 Aug 2024 16:02:37 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 2 Aug 2024 16:02:37 +0800 Message-ID: <7eb9436d-b4e5-4be1-adce-aa07cc493679@huawei.com> Date: Fri, 2 Aug 2024 16:02:36 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] mm: memory_hotplug: check hwpoisoned page firstly in do_migrate_range() Content-Language: en-US To: David Hildenbrand , Andrew Morton CC: Oscar Salvador , Miaohe Lin , Naoya Horiguchi , References: <20240725011647.1306045-1-wangkefeng.wang@huawei.com> <20240725011647.1306045-3-wangkefeng.wang@huawei.com> <0ff4a4ac-7b7b-4e07-a5da-a4c4e41438d6@redhat.com> From: Kefeng Wang In-Reply-To: <0ff4a4ac-7b7b-4e07-a5da-a4c4e41438d6@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Queue-Id: 794C040022 X-Stat-Signature: n1nbte1hs4cg8pichoqmikggwh7y1rip X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1722585761-61244 X-HE-Meta: U2FsdGVkX18o7fxGFh9LH/lgOiWU8bo2xa8OIPkxlSl/7X1oNK7uFgIEbxhYiLPwJWHdVgr2O2VE/7ozed5V+Ck4pzCQS5VEehLw8p5M6oHrJjV2PWp6cBHjbP8PYCrQleOKI2yEz4mejAs/3XrHQz2ZlHHTudDnp12cAxJgIt+MbJ4NGWCTbqXvo1IEvldzLWMVKhauUCdxE5FrIfvLbKhnSv5mOPhz9QPQeQge+TmNoqwzDb7OlNHh0eiJxxr03b/5R6bT68m9l/u1KeejrXj04sculxBuRALYtyOkL7KIRO5C/FzQJW/QoCMj2oDOpIwutUf3lh2bT3wNgg0uPQ6MbClQhPI+SCWkEAM/Gz1ZALkZi8ue09CMKOHAJwK93irnCrd4HipDKOK2sAjgiTLs9st4LOOi17Jbaw4u1o4A6QAsSp3Gm7PiesD7Ha2YknBCUQTXeOTuTBi6xMOPIf9RYmqrkpYxP4mCw/N9/9RvGlkJJKXbHu9h33KjrMPw2EvVoznRNZ7c5GvJKvlgDGO3ifTu7ZWZFRA+P7IqKtqE9W9KPJW/vxTaJM8FjMb2KGPWPhpMo7jsvD4WRRaZRlm05qol/+4+GYc+88XVWWQGT99tyqOBrN/87Ll4OCNmR0qI+YRQNpnUvjXNTrg8gOdLXWRBws/VZDhQZiHCRtlhSnWSHrUdCgVPDTkKa0yOohQgzE9YFCoHpoJGfAAjT8/EoS9HZWx1TlkUCyji2bUThTGh359oBUcA2AkG1sN0sOp6X4aKLJVyyJa1ri0NsAQw1Qr2BNwIhRgideNu8ySar9ID21ZPcAwmK2N68zIhaOFgWx3O8X11/TDSR49xQgVR9HIby5Ou7SN0cKRCWcH0a9iawPAPBcG5HPbOpJHv3B30j4hxzVCRc4+RGEDeuDMQFx6qEX/U6HE4lp1czdbT7+ATF5kI907Qtq6pZuz7DydH+6+atlrW/at6xr1 aU3ENj6C 1c288gm32ZB8iVwiM9SLX9LZAQ0sqB6Dud/z/Ly4I1EzbvH7OR3SuyFso9eOQGlyDVY2wXItlAvUI/ezeg4U2ZmkoQvZ/FoMXS3PvQ5e3H6AVwdUzhR3ZCzXUHybGxKDKyy7zDUAoZYFS0X3JkKIvt/cffY5agxZvdsYuNSQOurAnwKvERelcaAD7VAo5wkT88Ve+ClUn8IkEtNUUaUy38+gZF501cqzJdxMTRkbWmwshjQdp2ycUpUKRTC6n3/n89gs4OxQBnFQUJOYfk/giVGIb7Ikh6tFyO6opp1BTW3jvapS5vdIuvBSljr4/dgyHeWVfpqFr8+J0yrnECq/EsIGd7w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/8/2 4:14, David Hildenbrand wrote: > On 25.07.24 03:16, Kefeng Wang wrote: >> The commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned >> pages to be offlined") don't handle the hugetlb pages, the dead loop >> still occur if offline a hwpoison hugetlb, luckly, after the commit >> e591ef7d96d6 ("mm,hwpoison,hugetlb,memory_hotplug: hotremove memory >> section with hwpoisoned hugepage"), the HPageMigratable of hugetlb >> page will be clear, and the hwpoison hugetlb page will be skipped in >> scan_movable_pages(), so the deed loop issue is fixed. >> >> However if the HPageMigratable() check passed(without reference and >> lock), the hugetlb page may be hwpoisoned, it won't cause issue since >> the hwpoisoned page will be handled correctly in the next movable >> pages scan loop, and it will be isolated in do_migrate_range() and >> but fails to migrated. In order to avoid the unnecessary isolation and >> unify all hwpoisoned page handling, let's unconditionally check hwpoison >> firstly, and if it is a hwpoisoned hugetlb page, try to unmap it as >> the catch all safety net like normal page does. >> >> Signed-off-by: Kefeng Wang >> --- >>   mm/memory_hotplug.c | 27 ++++++++++++++++----------- >>   1 file changed, 16 insertions(+), 11 deletions(-) >> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >> index 66267c26ca1b..ccaf4c480aed 100644 >> --- a/mm/memory_hotplug.c >> +++ b/mm/memory_hotplug.c >> @@ -1788,28 +1788,33 @@ static void do_migrate_range(unsigned long >> start_pfn, unsigned long end_pfn) >>           folio = page_folio(page); >>           head = &folio->page; >> -        if (PageHuge(page)) { >> -            pfn = page_to_pfn(head) + compound_nr(head) - 1; >> -            isolate_hugetlb(folio, &source); >> -            continue; >> -        } else if (PageTransHuge(page)) >> -            pfn = page_to_pfn(head) + thp_nr_pages(page) - 1; >> - >>           /* >>            * HWPoison pages have elevated reference counts so the >> migration would >>            * fail on them. It also doesn't make any sense to migrate >> them in the >>            * first place. Still try to unmap such a page in case it is >> still mapped >> -         * (e.g. current hwpoison implementation doesn't unmap KSM >> pages but keep >> -         * the unmap as the catch all safety net). >> +         * (keep the unmap as the catch all safety net). >>            */ >> -        if (PageHWPoison(page)) { >> +        if (unlikely(PageHWPoison(page))) { >> +            folio = page_folio(page); >> + >>               if (WARN_ON(folio_test_lru(folio))) >>                   folio_isolate_lru(folio); >> + >>               if (folio_mapped(folio)) >> -                try_to_unmap(folio, TTU_IGNORE_MLOCK); >> +                unmap_posioned_folio(folio, TTU_IGNORE_MLOCK); >> + >> +            if (folio_test_large(folio)) >> +                pfn = folio_pfn(folio) + folio_nr_pages(folio) - 1; >>               continue; >>           } >> +        if (PageHuge(page)) { >> +            pfn = page_to_pfn(head) + compound_nr(head) - 1; >> +            isolate_hugetlb(folio, &source); >> +            continue; >> +        } else if (PageTransHuge(page)) >> +            pfn = page_to_pfn(head) + thp_nr_pages(page) - 1; > > If we can use a folio in the PageHWPoison() case, can we use one here as > well? I know that it's all unreliable when not holding a folio > reference, and we have to be a bit careful. Using a folio here is part of patch4, I want to unify hugetlb/thp(or large folio) with "pfn = folio_pfn(folio) + folio_nr_pages(folio) - 1" when large folio after get a ref. > > It feels like using folios here would mostly be fine, because things > like PageHuge() already use folios internally. > > And using it in the PageHWPoison() but not here looks a bit odd. We will convert to use folio in the following patch. > > The important part is that we don't segfault if we'd overshoot our target. >