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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3CB7C433B4 for ; Thu, 6 May 2021 04:01:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 25DE2611ED for ; Thu, 6 May 2021 04:01:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 25DE2611ED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=sangfor.com.cn Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 584EB6B006C; Thu, 6 May 2021 00:01:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 522286B006E; Thu, 6 May 2021 00:01:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C3216B0070; Thu, 6 May 2021 00:01:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 1FA8A6B006C for ; Thu, 6 May 2021 00:01:42 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D8560181AC9CC for ; Thu, 6 May 2021 04:01:41 +0000 (UTC) X-FDA: 78109457202.18.1EE35EC Received: from mail-m121142.qiye.163.com (mail-m121142.qiye.163.com [115.236.121.142]) by imf30.hostedemail.com (Postfix) with SMTP id 41907E000119 for ; Thu, 6 May 2021 04:01:14 +0000 (UTC) Received: from [0.0.0.0] (unknown [14.154.28.254]) by mail-m121142.qiye.163.com (Hmail) with ESMTPA id 8CE89802A7; Thu, 6 May 2021 12:01:36 +0800 (CST) Subject: Re: [RFC PATCH] mm/page_alloc: fix counting of free pages after take off from buddy To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , David Hildenbrand Cc: "akpm@linux-foundation.org" , "osalvador@suse.de" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" References: <20210421020426.5914-1-dinghui@sangfor.com.cn> <20210506024943.GA1777607@hori.linux.bs1.fc.nec.co.jp> From: Ding Hui Message-ID: <33be44ea-f377-c049-03ff-3b45289ab5f7@sangfor.com.cn> Date: Thu, 6 May 2021 12:01:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210506024943.GA1777607@hori.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSE83V1ktWUFJV1kPCR oVCBIfWUFZQk4aHlYaQkMYSUJOTRgeHRhVEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVUpKS0 9ISVVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Py46Ljo6GD8WFkMUThoMHzcz MA4KFCFVSlVKTUlLSUxITUJMSkJMVTMWGhIXVR8SFRwTDhI7CBoVHB0UCVUYFBZVGBVFWVdZEgtZ QVlKT1VKTk9VSUNVSU5PWVdZCAFZQU1LSUI3Bg++ X-HM-Tid: 0a793fd69030b037kuuu8ce89802a7 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 41907E000119 Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=sangfor.com.cn; spf=pass (imf30.hostedemail.com: domain of dinghui@sangfor.com.cn designates 115.236.121.142 as permitted sender) smtp.mailfrom=dinghui@sangfor.com.cn X-Rspamd-Server: rspam04 X-Stat-Signature: n6fkesaxdoq7ijhqboqkhbngoyexcxk8 Received-SPF: none (sangfor.com.cn>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=mail-m121142.qiye.163.com; client-ip=115.236.121.142 X-HE-DKIM-Result: none/none X-HE-Tag: 1620273674-462898 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 2021/5/6 10:49, HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3 =E7=9B=B4=E4=B9=9F)= wrote: > On Wed, Apr 28, 2021 at 04:54:59PM +0200, David Hildenbrand wrote: >> On 21.04.21 04:04, Ding Hui wrote: >>> Recently we found there is a lot MemFree left in /proc/meminfo after >>> do a lot of pages soft offline. >>> >>> I think it's incorrect since NR_FREE_PAGES should not contain HWPoiso= n pages. >>> After take_page_off_buddy, the page is no longer belong to buddy >>> allocator, and will not be used any more, but we maybe missed account= ing >>> NR_FREE_PAGES in this situation. >>> >>> Signed-off-by: Ding Hui >>> --- >>> mm/page_alloc.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>> index cfc72873961d..8d65b62784d8 100644 >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -8947,6 +8947,7 @@ bool take_page_off_buddy(struct page *page) >>> del_page_from_free_list(page_head, zone, page_order); >>> break_down_buddy_pages(zone, page_head, page, 0, >>> page_order, migratetype); >>> + __mod_zone_page_state(zone, NR_FREE_PAGES, -1); >>> ret =3D true; >>> break; >>> } >>> >> >> Should this use __mod_zone_freepage_state() instead? >=20 > Yes, __mod_zone_freepage_state() looks better to me. >=20 > And I think that maybe an additional __mod_zone_freepage_state() in > unpoison_memory() is necessary to cancel the decrement. I thought of t= he > following, but it doesn't build because get_pfnblock_migratetype() is > available only in mm/page_alloc.c, so you might want to add a small exp= orted > routine in mm/page_alloc.c and let it called from unpoison_memory(). >=20 > @@ -1899,8 +1899,12 @@ int unpoison_memory(unsigned long pfn) > } > =20 > if (!get_hwpoison_page(p, flags, 0)) { > - if (TestClearPageHWPoison(p)) > + if (TestClearPageHWPoison(p)) { > + int migratetype =3D get_pfnblock_migratetype= (p, pfn); > + > num_poisoned_pages_dec(); > + __mod_zone_freepage_state(page_zone(p), 1, m= igratetype); > + } > unpoison_pr_info("Unpoison: Software-unpoisoned free= page %#lx\n", > pfn, &unpoison_rs); > return 0; >=20 I think there is another problem: In normal case, we keep the last refcount of the hwpoison page, so=20 get_hwpoison_page should return 1. The NR_FREE_PAGES will be adjusted=20 when call put_page. At race condition, we maybe leak the page because we does not put it=20 back to buddy in unpoison_memory, however the HWPoison flag,=20 num_poisoned_pages, NR_FREE_PAGES is adjusted correctly. CPU0 CPU1 soft_offline_page soft_offline_free_page page_handle_poison take_page_off_buddy SetPageHWPoison unpoison_memory if (!get_hwpoison_page(p)) TestClearPageHWPoison num_poisoned_pages_dec __mod_zone_freepage_state return 0 /* miss put the page back to buddy */ page_ref_inc num_poisoned_pages_inc How about do nothing and return -EBUSY (so the caller can retry) if=20 unpoison a zero refcount page , or return 0 like 230ac719c500=20 ("mm/hwpoison: don't try to unpoison containment-failed pages") does ? @@ -1736,11 +1736,9 @@ int unpoison_memory(unsigned long pfn) } if (!get_hwpoison_page(p, flags, 0)) { - if (TestClearPageHWPoison(p)) - num_poisoned_pages_dec(); - unpoison_pr_info("Unpoison: Software-unpoisoned free page=20 %#lx\n", + unpoison_pr_info("Unpoison: Software-unpoisoned zero refcount=20 page %#lx\n", pfn, &unpoison_rs); - return 0; + return -EBUSY; } lock_page(page); =09 --=20 Thanks, - Ding Hui