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=-10.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, 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 F3F3EC48BE5 for ; Sat, 19 Jun 2021 12:23:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6FAE76120A for ; Sat, 19 Jun 2021 12:23:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FAE76120A 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 AA9E36B006E; Sat, 19 Jun 2021 08:23:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5A0D6B0070; Sat, 19 Jun 2021 08:23:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 921E36B0072; Sat, 19 Jun 2021 08:23:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 5DE3D6B006E for ; Sat, 19 Jun 2021 08:23:46 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E5C2BD227 for ; Sat, 19 Jun 2021 12:23:45 +0000 (UTC) X-FDA: 78270389610.08.AC7E864 Received: from mail-m118208.qiye.163.com (mail-m118208.qiye.163.com [115.236.118.208]) by imf29.hostedemail.com (Postfix) with SMTP id 7043E42D for ; Sat, 19 Jun 2021 12:23:42 +0000 (UTC) Received: from 2CD-RMPB.local (unknown [113.118.120.96]) by mail-m118208.qiye.163.com (Hmail) with ESMTPA id DEC93E01C3; Sat, 19 Jun 2021 20:23:36 +0800 (CST) Subject: Re: [PATCH v1 6/6] mm/hwpoison: fix unpoison_memory() To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= Cc: Naoya Horiguchi , "linux-mm@kvack.org" , Andrew Morton , David Hildenbrand , Oscar Salvador , Michal Hocko , Tony Luck , "Aneesh Kumar K.V" , "linux-kernel@vger.kernel.org" References: <20210614021212.223326-1-nao.horiguchi@gmail.com> <20210614021212.223326-7-nao.horiguchi@gmail.com> <94984984-f123-85ae-20bc-b40e90d536f6@sangfor.com.cn> <20210618083625.GA2215283@hori.linux.bs1.fc.nec.co.jp> From: Ding Hui Message-ID: Date: Sat, 19 Jun 2021 20:22:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20210618083625.GA2215283@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 oVCBIfWUFZGhpJS1ZCH0xMHU4fSUpDS09VEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVUpKS0 hKTFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OBA6GBw5ST9DUTpKPyk6ODpW HigaCi9VSlVKTUlPSktOT0pMTkhCVTMWGhIXVR8SFRwTDhI7CBoVHB0UCVUYFBZVGBVFWVdZEgtZ QVlKSkhVSkpDVUpJS1VCTVlXWQgBWUFPQ01PNwY+ X-HM-Tid: 0a7a2439fa1f2c17kusndec93e01c3 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 7043E42D X-Stat-Signature: rn95kjak3tfsgrbu6wn65cxcje3corn1 Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of dinghui@sangfor.com.cn designates 115.236.118.208 as permitted sender) smtp.mailfrom=dinghui@sangfor.com.cn; dmarc=pass (policy=none) header.from=sangfor.com.cn X-HE-Tag: 1624105422-285325 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/6/18 4:36 =E4=B8=8B=E5=8D=88, HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3 = =E7=9B=B4=E4=B9=9F) wrote: > On Thu, Jun 17, 2021 at 06:00:21PM +0800, Ding Hui wrote: >> On 2021/6/14 10:12, Naoya Horiguchi wrote: >>> From: Naoya Horiguchi >>> >>> After recent soft-offline rework, error pages can be taken off from >>> buddy allocator, but the existing unpoison_memory() does not properly >>> undo the operation. Moreover, due to the recent change on >>> __get_hwpoison_page(), get_page_unless_zero() is hardly called for >>> hwpoisoned pages. So __get_hwpoison_page() mostly returns zero (mean= ing >>> to fail to grab page refcount) and unpoison just clears PG_hwpoison >>> without releasing a refcount. That does not lead to a critical issue >>> like kernel panic, but unpoisoned pages never get back to buddy (leak= ed >>> permanently), which is not good. >> >> As I mention in [1], I'm not sure about the exactly meaning of "broken= " in >> unpoison_memory(). >> >> Maybe the misunderstanding is: >> >> I think __get_hwpoison_page() mostly returns one for hwpoisoned page. >> In 06be6ff3d2ec ("mm,hwpoison: rework soft offline for free pages"), >> page_handle_poison() is introduced, it will add refcount for all >> soft-offlineed hwpoison page. >> In memory_failure() for hard-offline=EF=BC=8Cpage_ref_inc() called on = free page >> too, and for used page, we do not call put_page() after get_hwpoison_p= age() >> !=3D 0. >> So all hwpoisoned page refcount must be great than zero when >> unpoison_memory() if regardless of racy. >=20 > Hi, Ding, >=20 > Thanks for the comment. I feel that I failed to define the exact issue= in > unpoison. Maybe I saw and misinterpreted some random error as unpoison= 's > issue during developing other hwpoison patches, so please don't take se= rious > my previous wrong word "broken", sorry about that. >=20 > Anyway I reconsider how to handle this 6/6, maybe it will be a clear > description of the problem, and will be simplified. >=20 >> >> Recently I tested loop soft-offline random pages and unpoison them for= days, >> it works fine to me. (with bac9c6fa1f92 patched) >=20 > Thank you for testing, >=20 Hi Naoya, I'm afraid of my description about testing is ambiguous for others, let=20 me clarify that I ran stress soft-offline test case from mce-test=20 project (https://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git) for=20 days to verify my modify about NR_FREE_PAGES (bac9c6fa1f92), without=20 your current patchset, the case is loop soft-offline random pages and=20 unpoison them, and it works basic fine to me. --=20 Thanks, -dinghui