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 B7509C433EF for ; Mon, 9 May 2022 13:35:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 060546B0071; Mon, 9 May 2022 09:35:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2CAF6B0073; Mon, 9 May 2022 09:35:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF2DA6B0074; Mon, 9 May 2022 09:35:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id CC7EF6B0071 for ; Mon, 9 May 2022 09:35:05 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 90819305E6 for ; Mon, 9 May 2022 13:35:05 +0000 (UTC) X-FDA: 79446300570.04.5D6293E Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf27.hostedemail.com (Postfix) with ESMTP id 69D4240095 for ; Mon, 9 May 2022 13:35:02 +0000 (UTC) Date: Mon, 9 May 2022 22:34:53 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1652103302; h=from:from: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=q9HiAaC4YBMcUQ0+C1EKSJEM8bPqXy5gdXi8GIux1ts=; b=IEi6/agEu3wE2SDiCGuc2P+dXVFd36JGkqsBM3WbzoPsH/2hTctYPsBl/ZSAvTd7UYpJkO fK7MZApyS82Zt72JVUyrTyDHOlTdCkdEdV610CRPIXPZ/mFoQmwMEkb9jGNqxlchUyMt9t 26okPKmgc8CYL/oM6Kz3Yn/RAyMG1zU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Naoya Horiguchi To: Miaohe Lin Cc: HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+jIOebtOS5nyk=?= , Andrew Morton , Mike Kravetz , Yang Shi , Oscar Salvador , Muchun Song , "linux-kernel@vger.kernel.org" , Linux-MM Subject: Re: [RFC PATCH v1 4/4] mm, memory_hotplug: fix inconsistent num_poisoned_pages on memory hotremove Message-ID: <20220509133453.GA2511740@u2004> References: <20220427042841.678351-1-naoya.horiguchi@linux.dev> <20220427042841.678351-5-naoya.horiguchi@linux.dev> <828cc111-40e8-88ed-bb50-fb185e5f0304@huawei.com> <20220428040556.GA3945421@hori.linux.bs1.fc.nec.co.jp> <4cae9c00-a048-2c0a-9a45-d7abb956fde7@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4cae9c00-a048-2c0a-9a45-d7abb956fde7@huawei.com> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 69D4240095 X-Stat-Signature: 7inn3nqzza3a894a58e6x6awht8hmoi4 Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="IEi6/agE"; spf=pass (imf27.hostedemail.com: domain of naoya.horiguchi@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=naoya.horiguchi@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-HE-Tag: 1652103302-204396 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 Thu, Apr 28, 2022 at 03:16:01PM +0800, Miaohe Lin wrote: > On 2022/4/28 12:05, HORIGUCHI NAOYA(堀口 直也) wrote: > > On Thu, Apr 28, 2022 at 11:20:16AM +0800, Miaohe Lin wrote: > >> On 2022/4/27 12:28, Naoya Horiguchi wrote: > >>> From: Naoya Horiguchi > >>> > >>> When offlining memory section with hwpoisoned pages, the hwpoisons are > >>> canceled. But num_poisoned_pages is not updated for that event, so the > >>> counter becomes inconsistent. > >> > >> IIUC, this work is already done via clear_hwpoisoned_pages when __remove_pages. > >> Or am I miss something? > > > > Actually I had the same question when writing this patch, and found that > > __remove_pages() seems to be called from device memory or HMM, but not from > > It seems remove_memory (which calls __remove_pages) will be called as .detach callback of > memory_device_handler in drivers/acpi/acpi_memhotplug.c. So the hwpoison info will also be > clear for that memory ? Sorry, you're right. That code path also calls __remove_pages() and clear_hwpoisoned_pages(). So most major usecases of memory hotremove seems not to be affected by the reported problem. Thanks, Naoya Horiguchi