From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout01.his.huawei.com (canpmsgout01.his.huawei.com [113.46.200.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD31E432BDD for ; Mon, 6 Jul 2026 08:56:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.216 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783328169; cv=none; b=RSIUgfkm7UPD29kryOWSu7weLjJKkXNYr3nomHTWiHMYlBbYLMjiPZYXqx3n185dOa65seizXosGyqR+/aU91TRKG4l2ARYkSrfaBYPgL+O442tKB727vKqUJiCumIIaJzZqtuOsIoIQ/f7XJV7Np3Rs9iHCGsP18wjP9ngxdF8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783328169; c=relaxed/simple; bh=oPMMBjCtsx7cxjI9nDTpte2JYDsm5z4UeGMplmJUurw=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=cvI1S8RoARUiGzwp6eQMxCROF/sXfv6NKpzljAu6zeg+7NowsKpz+TwsZz90j+y72ee7JgfNUHMpo4JicHBhlDqNF/LJ+unrDSujHA2ah9TM4fDu83BnUn4iPLbcAmVVKqOgPT+dctYFjDlFOS078olUaxmsFkhq8ms/wTD/JII= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=zRCTH/CS; arc=none smtp.client-ip=113.46.200.216 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="zRCTH/CS" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=X2nPCRNNSh3ZipcyRGsxu95f/swOavphUSmg+jWuubo=; b=zRCTH/CSXlHBfmFgAvtvsLLee1l1ShxSlAcjEdrJkwwD8/Pt3mBMotBI/GYL7uYhENJGKK87T xWuuR4Au+G4SqRJU9aTrPbVlzeSv+gS3cf4RoMD/RC7z8jliX67vP5GMnC6q+E+FfGz+ORr/J0Y hzbfFZi+PpMXKbbGCpRtZDM= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout01.his.huawei.com (SkyGuard) with ESMTPS id 4gtydq3tM8z1T4gY; Mon, 6 Jul 2026 16:46:55 +0800 (CST) Received: from kwepemo200010.china.huawei.com (unknown [7.202.195.178]) by mail.maildlp.com (Postfix) with ESMTPS id 5C1FD203B8; Mon, 6 Jul 2026 16:55:53 +0800 (CST) Received: from huawei.com (10.44.142.85) by kwepemo200010.china.huawei.com (7.202.195.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Mon, 6 Jul 2026 16:55:52 +0800 From: Qi Xi To: Naoya Horiguchi , Andrew Morton , Sasha Levin , Greg Kroah-Hartman CC: Miaohe Lin , Jane Chu , , , , , Subject: [PATCH stable/linux-6.6.y] mm/memory-failure: fix missing ->mf_stats count when hugetlb folio already poisoned Date: Mon, 6 Jul 2026 16:41:18 +0800 Message-ID: <20260706084118.1284271-1-xiqi2@huawei.com> X-Mailer: git-send-email 2.33.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemo200010.china.huawei.com (7.202.195.178) When a new subpage is poisoned on a hugetlb folio that has already been marked hwpoison (MF_HUGETLB_FOLIO_PRE_POISONED), hugetlb_update_hwpoison() increments num_poisoned_pages directly, but the per-node ->mf_stats is not updated because this path bypasses action_result(). This leaves the two accounting counters inconsistent within the hardware memory-failure path: a new poison event is counted in num_poisoned_pages but not reflected in the per-node mf_stats. In mainline, commit a148a2040191 ("mm/memory-failure: fix missing ->mf_stats count in hugetlb poison") fixed this by removing the direct num_poisoned_pages_inc() from the helper and adding action_result() calls in try_memory_failure_hugetlb() for the already-poisoned cases. The backport to linux-6.6.y as commit 252bb328b36f ("mm/memory-failure: fix missing ->mf_stats count in hugetlb poison") applied the refactoring (naming, constants, switch-case) but omitted the core counting fix, leaving the inconsistency in place. Fix this by adding a matching update_per_node_mf_stats() call alongside the existing num_poisoned_pages_inc() in the same block, so both counters stay consistent without restructuring the error path. Fixes: 252bb328b36f ("mm/memory-failure: fix missing ->mf_stats count in hugetlb poison") Signed-off-by: Qi Xi --- mm/memory-failure.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 86cdf36ee3bb..5f9203bf8ec1 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1947,8 +1947,10 @@ static int hugetlb_update_hwpoison(struct folio *folio, struct page *page) raw_hwp->page = page; llist_add(&raw_hwp->node, head); /* the first error event will be counted in action_result(). */ - if (ret) + if (ret) { num_poisoned_pages_inc(page_to_pfn(page)); + update_per_node_mf_stats(page_to_pfn(page), MF_FAILED); + } } else { /* * Failed to save raw error info. We no longer trace all -- 2.33.0