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 48426C6379F for ; Mon, 20 Feb 2023 11:39:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B83216B0073; Mon, 20 Feb 2023 06:39:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B326E6B0074; Mon, 20 Feb 2023 06:39:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A21B96B0075; Mon, 20 Feb 2023 06:39:05 -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 91F236B0073 for ; Mon, 20 Feb 2023 06:39:05 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 60B6D121019 for ; Mon, 20 Feb 2023 11:39:05 +0000 (UTC) X-FDA: 80487473850.17.9B7E86B Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by imf25.hostedemail.com (Postfix) with ESMTP id B811BA001F for ; Mon, 20 Feb 2023 11:39:00 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf25.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676893143; 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=uPeBFv/oR8CgHcyDrbwoQVf8f9bMannaYfVIMcHN1QY=; b=Ybvs0o9d2+/cOxI8CffA3vJduMJiyx59GR+Z3rIWtCOevz18uNO/rWtm4Zsv4DTFQr+sLd 6S30FlZYMgblKhyofudJ+/Rfx5FzjKVD+OK4EQkSxh4E3OHlmeqGYA26Tse0Y4Sa26wzCk x6HOt/UezHsKPfDSScqNbxfHqrgiMzI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf25.hostedemail.com: domain of xueshuai@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=xueshuai@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676893143; a=rsa-sha256; cv=none; b=khQ4xvG8uhyznR+wLwLi0sD02j9C25KBXjuW0zLXHwklN5iaLzzYD8a/F+lcQMAEE4Mshl +/hkfddY4E7eFuguBZQwV3q1NFMlnx5uJznfwurKBcX/iT+3GNDQgzpYBzL4rKZxhHOdaP IIMnxLhgxYnx2AdIIQYd7CcHWgWxyjk= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R301e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046051;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0Vc6o5S0_1676893136; Received: from 30.240.112.34(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0Vc6o5S0_1676893136) by smtp.aliyun-inc.com; Mon, 20 Feb 2023 19:38:57 +0800 Message-ID: <229b741a-5fa4-4886-800e-445ff7471b87@linux.alibaba.com> Date: Mon, 20 Feb 2023 19:38:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [PATCH 0/6] hwpoison, shmem, hugetlb: fix data loss issue 5.10.y To: Mike Kravetz , stable@vger.kernel.org, linux-mm@kvack.org Cc: Yang Shi , Naoya Horiguchi , James Houghton , Oscar Salvador , Miaohe Lin , Muchun Song , Andrew Morton References: <20221123195408.135161-1-mike.kravetz@oracle.com> Content-Language: en-US From: Shuai Xue In-Reply-To: <20221123195408.135161-1-mike.kravetz@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B811BA001F X-Stat-Signature: 6gzu6sa5b3zmubn6zx8e8gxgoq8569fa X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1676893140-242551 X-HE-Meta: U2FsdGVkX1++xV4CC1e70xaTrra7OzConyf5H2O4R3zE+rj3h9qXCj2Qk6lxpXdtsHo60f4yqCMhGYB2oxwe9m5HlqzmlK36l9QZmfZLxGmCUmgnhSx28AvfesSN+SMdLNs2+5DCBjmCmHdm3siOYbYcNugpt7wmRSbJxJg3sfa9W+YSP7+iBy0Uo2mey4+Edr7aTO2B+yxi7KPrKCLCp7Hw1jxAhso/Btn1VEKzCzbeusxQp4/qgQ9t4wMkk1zq4qpXVSej0v6XIjhL3rEBIT4ZR0yHUm0lS/42cmTGHO8b+NXCz9uYGfsG9uqwfWSca5qq+oqq4wcuhZTaGMVeuMVEjBUNW4uixa4gxESC1+y2dBcmMs+ZbMKPgaLb3qAvon+hdvjZhAVGG/b+UZ+cflp42Euy25ufFPKTpjM4SbmLTLI+5UvqH9AiXDGZT6G0Trm58T0HqTl4GQeZiKm+MADRTX4G1FUjHOZE1wn61ZoG1urYwTyfAKUTuqCj26qRJKNEldVNuM2jT3mgbpmjKpXxNPuQ3k0ymOJdpykok2387NnfdPJIN4/8SSg6kVow+vJz4SFDChaHtjcWmQCrdPMVENCj5efWmoWO+nFSY4F0yfApELI87FDVb3h+2s1KXKCkoXmzskGVD8Ee3k/bdUu76TcRB6ORNF2KxivrNcQ0f3O7Nnw4it/NcVIlgu/1zmb/c0MOyj2cChb7EybRvgTzN5Io6GuYOcmfu6S4C8CtnOtXBd95p89xz1sgCxY3rSnHJxhFY9cGo9udwgpx23fskPg1vLkrB7Nt/l54g/saYk/O+B1uWBNF3mPI2Ccsi0t+8nNZxJNYJDq6wcIPpxAZ7ev3oT8yVt3H7mrFqlkifzT1q0nrCbOMEm9axklAIgWiUZkemWSXxTjL9LqEijSdZRtAW1dfQKKgKDjklmckt8H+McrFK2xJi4Sgw3OhbczYdI68CKERWwWZQh1 0l+oN8ea PKO2TUpiducYaVnoG/KvdNIKFPgNmWW5d8QOEOkUn5ctB+G8KsZlePgq0E9z39Z2fJtUTIIr79K//z8VMp7SUHWlt/bNozhK9L8RHloqAam89k2HK9bA5YcvDf5m9x59jMwdXjQ6OfiPdMpnRiv1SS7VxqCSO4whr3leaw/nDH2/f1Djzho8eMcOnRdEBM3ngjqIfAqlT+uHkfMUZZdJpj1nxiQ== 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 2022/11/24 AM3:54, Mike Kravetz wrote: > This is a request for adding the following patches to stable 5.10.y. > > Poisoned shmem and hugetlb pages are removed from the pagecache. > Subsequent access to the offset in the file results in a NEW zero > filled page. Application code does not get notified of the data > loss, and the only 'clue' is a message in the system log. Data > loss has been experienced by real users. > > This was addressed upstream. Most commits were marked for backports, > but some were not. This was discussed here [1] and here [2]. > > Patches apply cleanly to v5.4.224 and pass tests checking for this > specific data loss issue. LTP mm tests show no regressions. > > All patches except 4 "mm: hwpoison: handle non-anonymous THP correctly" > required a small bit of change to apply correctly: mostly for context. > > linux-mm Cc'ed as it would be great to get at least an ACK from others > familiar with this issue. > > [1] https://lore.kernel.org/linux-mm/Y2UTUNBHVY5U9si2@monkey/ > [2] https://lore.kernel.org/stable/20221114131403.GA3807058@u2004/ > > James Houghton (1): > hugetlbfs: don't delete error page from pagecache > > Yang Shi (5): > mm: hwpoison: remove the unnecessary THP check > mm: filemap: check if THP has hwpoisoned subpage for PMD page fault > mm: hwpoison: refactor refcount check handling > mm: hwpoison: handle non-anonymous THP correctly > mm: shmem: don't truncate page if memory failure happens > > fs/hugetlbfs/inode.c | 13 ++-- > include/linux/page-flags.h | 23 ++++++ > mm/huge_memory.c | 2 + > mm/hugetlb.c | 4 + > mm/memory-failure.c | 153 ++++++++++++++++++++++++------------- > mm/memory.c | 9 +++ > mm/page_alloc.c | 4 +- > mm/shmem.c | 51 +++++++++++-- > 8 files changed, 191 insertions(+), 68 deletions(-) > Hi, folks Thank you for your effort. Data loss will break the data consistency of end users and it is critical to notify users. I tried to apply this patch set to 5.10.168 stable release[1] and run mm_regression[3] test cases following steps[4] provided by Naoya. All four cases passed. #./run.sh project summary -p Project Name: debug PASS mm/hwpoison/shmem_link/link-hard.auto3 PASS mm/hwpoison/shmem_link/link-sym.auto3 PASS mm/hwpoison/shmem_rw/thp-always.auto3 PASS mm/hwpoison/shmem_rw/thp-never.auto3 Progress: 4 / 4 (100%) Tested-by: Shuai Xue Cheers, Shuai [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.168 [2] https://github.com/nhoriguchi/mm_regression [3] https://lore.kernel.org/stable/20221116235842.GA62826@u2004/