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 15182C021AA for ; Wed, 19 Feb 2025 06:35:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 99E1F2801F9; Wed, 19 Feb 2025 01:35:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 94E582801F6; Wed, 19 Feb 2025 01:35:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 815632801F9; Wed, 19 Feb 2025 01:35:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5CB082801F6 for ; Wed, 19 Feb 2025 01:35:01 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C0B60140F90 for ; Wed, 19 Feb 2025 06:35:00 +0000 (UTC) X-FDA: 83135731560.14.DFA2E3B Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf16.hostedemail.com (Postfix) with ESMTP id 7A006180006 for ; Wed, 19 Feb 2025 06:34:56 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739946898; 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=VJLQcNg5pvAwpYgf/WVSSNkHaCLVnCPeMU6IEjni6O4=; b=2yxg8h9ssRKeptqwPNF6POLrkT80+ODFmpVdfHblcRLaadBwx/pvQVZscD9iyhkIWD2av+ 6Huoip83e0remwovznhxHquAflvq/Uw/1Ha0gcfl55AhVOFwDpO9ZOm1qaJF0ZRq1TwE7E B4jZI92zM6ncNp/bJ5iepFdTrBqlNrw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739946898; a=rsa-sha256; cv=none; b=ip6QgjXpzwj8h5hYzWcp9auoppJx1npuwU+W9cLacHPpAYE+U7VCZk0K/XJpphdh3l0cYU x3ZsJuKnveL5CHo+s4gyzTFxuAftnMU1K392zeuVEyzSfBTPT1AbvX3IhZMEYUFhDsD+RN +pslyVi6QpJkcDp4yZQMCNq0Z7VDQAM= Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4YyRMr1d4vz1Y1t2; Wed, 19 Feb 2025 14:30:16 +0800 (CST) Received: from kwepemd200019.china.huawei.com (unknown [7.221.188.193]) by mail.maildlp.com (Postfix) with ESMTPS id 0897A140159; Wed, 19 Feb 2025 14:34:52 +0800 (CST) Received: from [10.173.127.72] (10.173.127.72) by kwepemd200019.china.huawei.com (7.221.188.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 19 Feb 2025 14:34:50 +0800 Subject: Re: [PATCH v2 4/5] mm/hwpoison: Fix incorrect "not recovered" report for recovered clean pages To: Shuai Xue CC: , , , , , , , , , , , , , , , References: <20250217063335.22257-1-xueshuai@linux.alibaba.com> <20250217063335.22257-5-xueshuai@linux.alibaba.com> From: Miaohe Lin Message-ID: Date: Wed, 19 Feb 2025 14:34:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20250217063335.22257-5-xueshuai@linux.alibaba.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.127.72] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemd200019.china.huawei.com (7.221.188.193) X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7A006180006 X-Stat-Signature: d86i5feq3pfwsqacxs3j7e61qs41ih6i X-HE-Tag: 1739946896-861533 X-HE-Meta: U2FsdGVkX1/3/LJj6W3cYLzoMB/burGnvhtkXSjD4SFNslM5H/yQusYiWdNW6Im4P86nDIWSo7IC1K3l8gcdgG+l5S3VDROR5Qwn7sAxAog59i5oBKfBGOGKWReQ+zAAzvOOsbLwjJqIV6LfcfjXIsFVMaSg8F7HMWC+sM/V0SvSLwMH9lTDDN0AEjRK3q32AgjIfxbMF8Bxd+nils0DiaioNZUjkf8OwmrxYruj/+MiqBMNCSh3/lBC6GRQqZ7lw1GqxBKAGRNa9iZWCQL8+dczp+jdZEgNi+ZWZsXOgrQ56ogpLCi1GOmjFPMVp9adKo2KYBPuskVlBj2DJDy9Qzb4gHi8DlGN0UKLgq5JItMu/O+n+9JfWMRl7sNVNfwWR1P6oPVm9vbmGIxB7Qf8p6KpD5Mix6D2A5j5OlqwEMWORiMAirIet+NcozXRv2TpN7BrNQIowfveaPhgRFznlFJ3KBR9Faume1xmOIgxL5whJe2UWKv94RAX7ODdujprjzDCOF1JXyLolqHoNJGLSnvLgIm5oVKp2EPwCtBzn1MXpU6iAazQyGtlPYR029Jf8SSyfBeeAHSvLaU+xmYpgQPiX4UpswMhA00yWOTSLpELDtMprlMKypSTB8HVvgo4EhiJ/9dd0MQ7M2ZV6l7Zv/1CNWS5iqqw8CVLl+HmweiLcyzkOtyPSfiKUE0JtbGjgGdv4vxLRqRD91XXGjtk8GyAe2wiKMLuGqk29hnodrgeU2uWxzD5sW2EcU0F4TKXsHsNBvgo3azjUX9MLCuJvNM1SPAfHJqqfKbsEUCVR3ztD55CZBLaVbhS01n/bvshgYhWiK/XkjNuEEnA5bj+0tiqNcz+TvKDfNwILcXQ7k8PtkRrBFnYFWApOP+AMKcHpvuV/xrBKjkKfyTQPTQXESS/PI/EmgGSvq/3dhizTGsxHqrsG+3sH63IpTupiv+5l8Lit16I3FIKezLIAMc 7zRSK6Ka LZR+5jkIh/k60QRdS0DuIgyt5TaulgcAVW8pEqXdICXCuDzqM6/n5pv/+QxV6xoZ0WZBCHJvDEDdAWEFSk3SADSqoqOOHgqMubFInvFls7efOqkG05SWhHs4omjnn7gEf4sT0y8lfuuQj5IAYUTS+EJit271JTO4cmbaH5BTFiYqFDNBa82FQP4PSFletijVT4+YNehh444kd37AuB1qQQFVNC2NYwG4gFgdnZm1JSl6fqzxn1k3nBSNrE1XELj3ELUy50OxXx5zbjg/LtYN6FQp2vW9ycHPh/4kBPkCFOqRjdv8lqE+vmTwkwg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000808, 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 2025/2/17 14:33, Shuai Xue wrote: > When an uncorrected memory error is consumed there is a race between > the CMCI from the memory controller reporting an uncorrected error > with a UCNA signature, and the core reporting and SRAR signature > machine check when the data is about to be consumed. > > If the CMCI wins that race, the page is marked poisoned when > uc_decode_notifier() calls memory_failure(). For dirty pages, > memory_failure() invokes try_to_unmap() with the TTU_HWPOISON flag, > converting the PTE to a hwpoison entry. As a result, > kill_accessing_process(): > > - call walk_page_range() and return 1 regardless of whether > try_to_unmap() succeeds or fails, > - call kill_proc() to make sure a SIGBUS is sent > - return -EHWPOISON to indicate that SIGBUS is already sent to the > process and kill_me_maybe() doesn't have to send it again. > > However, for clean pages, the TTU_HWPOISON flag is cleared, leaving the > PTE unchanged and not converted to a hwpoison entry. Conversely, for > clean pages where PTE entries are not marked as hwpoison, > kill_accessing_process() returns -EFAULT, causing kill_me_maybe() to > send a SIGBUS. > > Console log looks like this: > > Memory failure: 0x827ca68: corrupted page was clean: dropped without side effects > Memory failure: 0x827ca68: recovery action for clean LRU page: Recovered > Memory failure: 0x827ca68: already hardware poisoned > mce: Memory error not recovered > > To fix it, return 0 for "corrupted page was clean", preventing an > unnecessary SIGBUS. > > Fixes: 046545a661af ("mm/hwpoison: fix error page recovered but reported "not recovered"") > Signed-off-by: Shuai Xue > Cc: stable@vger.kernel.org > --- > mm/memory-failure.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index 995a15eb67e2..b037952565be 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -881,12 +881,17 @@ static int kill_accessing_process(struct task_struct *p, unsigned long pfn, > mmap_read_lock(p->mm); > ret = walk_page_range(p->mm, 0, TASK_SIZE, &hwpoison_walk_ops, > (void *)&priv); > + /* > + * ret = 1 when CMCI wins, regardless of whether try_to_unmap() > + * succeeds or fails, then kill the process with SIGBUS. > + * ret = 0 when poison page is a clean page and it's dropped, no > + * SIGBUS is needed. > + */ > if (ret == 1 && priv.tk.addr) > kill_proc(&priv.tk, pfn, flags); > - else > - ret = 0; > mmap_read_unlock(p->mm); > - return ret > 0 ? -EHWPOISON : -EFAULT; > + > + return ret > 0 ? -EHWPOISON : 0; The caller kill_me_maybe will do set_mce_nospec + sync_core again. static void kill_me_maybe(struct callback_head *cb) { struct task_struct *p = container_of(cb, struct task_struct, mce_kill_me); int flags = MF_ACTION_REQUIRED; ... ret = memory_failure(pfn, flags); if (!ret) { set_mce_nospec(pfn); sync_core(); return; } Is this expected? Thanks. .