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 69BAAC6FD1D for ; Tue, 4 Apr 2023 18:44:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D56206B0071; Tue, 4 Apr 2023 14:44:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D047D6B0074; Tue, 4 Apr 2023 14:44:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCD9F6B0075; Tue, 4 Apr 2023 14:44:30 -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 A99406B0071 for ; Tue, 4 Apr 2023 14:44:30 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7841C1A0995 for ; Tue, 4 Apr 2023 18:44:30 +0000 (UTC) X-FDA: 80644584300.11.8BEB376 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf11.hostedemail.com (Postfix) with ESMTP id 83B7A4000A for ; Tue, 4 Apr 2023 18:44:28 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KH3vz08s; spf=pass (imf11.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=jiaqiyan@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680633868; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uaHM+qhD9qU7/ep6xrswNxdUjVzuMJ9uZzOpntVTvas=; b=GFyXL11MzwEcxDSqZs8nBHPNFrrpp2/kC2B4csa2/NE2zIkBuBRUHSMpoP7M/dEjC1ZVRU C1KHU6bISC/WfWGQ4+/oSm4SksAdYZJKL6OA4KshMDZ29bzq6wBjCn5MGPP1lPzhn7nS8B mscRdbOVxvH1RGujFPSGLMunf9lfuSg= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KH3vz08s; spf=pass (imf11.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=jiaqiyan@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680633868; a=rsa-sha256; cv=none; b=e3+5nnLFUou6HFAukGrcaANEb0G9YXGqSnQE99Uc6J3/kvPYuZpy9qraGbO9BZbTDDD6uF ACwMvMVy/13NJreDkoYYfJnFEd8PdYaZWaKx7jlY4vqK8V3B0G/F2ERZvO1vPRc/ymQxFK qeamfyRzPI7TBP65zgROWTU9lo3E9hY= Received: by mail-yb1-f179.google.com with SMTP id j7so39907585ybg.4 for ; Tue, 04 Apr 2023 11:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680633867; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uaHM+qhD9qU7/ep6xrswNxdUjVzuMJ9uZzOpntVTvas=; b=KH3vz08s1dy8vfwmrhZn+K2O0wheJsxfa4CXWYSBIR+GHgj+ZcypWl1QiJkzsRerxL +NzOuEtLTV1dcxW0TBUg77RFJfQf/AjkNZf4FVqd1fFudGubkmFWCjPG91PM74K+Ue+C MyKrS0E3MfOUVSbp4/ORMmxjC1IDHUSKqt+GzJAXYbo6B5qEzAzcMI10MSzufeaZXt/r o0CB4FB537srrXlTv64QAWYzTSY/kzp78Y/3WuHpQOLR18iB14YWMNS4t20dP4b1ZCXB fnjgLK5VF4gzDytBT6+QH48mhCdQ1rBsxtz2PA9aMzRZG+ygwVYuXcDvUtp3lPvAcKqz KOfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680633867; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uaHM+qhD9qU7/ep6xrswNxdUjVzuMJ9uZzOpntVTvas=; b=LosCy40ZoSoCdxCKpqpuRFyvt0Ielo+KSGhfMfWsUruZE2qAue1jCmeDbiwzk1Po+E 6Bc/rc84ovXl94oLL/BBolcZJLKWHJn7QCbQeDEHp1M89n9N4T+6YegqKOX+DJI3qRwb n86mY5IkVBZw8EHi2+vi4Wo5BNDF+v4cashsyDn91nIanuSFM7xBuhtf3jWeAIl4gbBb UnOZ+mE1sWFckjtgJ4wSzvli158kZyCGpq+LrEDIpE5OewboTR1nvN7ubeMTIH7HWZac BVMy8gqfoy8UOk9U2lnE2ev1JoTZLPD/ZOAXARwh5jsSvgJcnyq99KSnVLg8IoKGjju2 LQRQ== X-Gm-Message-State: AAQBX9d3rwe31uD/akIyLinHLQ2kV3ce6apUkFZ7P6Os25ub9LZNOOjA zrpA7nFsS9PpMYBEnn5zPo1U2YpoAGhMPDK02dQj8A== X-Google-Smtp-Source: AKy350anb4iSivXUw9/IMIRdcBXyGak1j2GOWIqNLocdHGhOEz2w45CC7O1aiQP1kY0vDr9CoGMcBGJwcMfsUcctcQI= X-Received: by 2002:a25:d406:0:b0:b7d:4c96:de0 with SMTP id m6-20020a25d406000000b00b7d4c960de0mr2150009ybf.5.1680633867463; Tue, 04 Apr 2023 11:44:27 -0700 (PDT) MIME-Version: 1.0 References: <20230329151121.949896-1-jiaqiyan@google.com> In-Reply-To: <20230329151121.949896-1-jiaqiyan@google.com> From: Jiaqi Yan Date: Tue, 4 Apr 2023 11:44:16 -0700 Message-ID: Subject: Re: [PATCH v12 0/3] Memory poison recovery in khugepaged collapsing To: kirill.shutemov@linux.intel.com, kirill@shutemov.name, shy828301@gmail.com, tongtiangen@huawei.com, tony.luck@intel.com Cc: naoya.horiguchi@nec.com, linmiaohe@huawei.com, linux-mm@kvack.org, akpm@linux-foundation.org, osalvador@suse.de, wangkefeng.wang@huawei.com, stevensd@chromium.org, hughd@google.com Content-Type: multipart/alternative; boundary="000000000000ab659505f887105b" X-Stat-Signature: oizny9uexe1awuedbmfo5kpjy3ohjr51 X-Rspam-User: X-Rspamd-Queue-Id: 83B7A4000A X-Rspamd-Server: rspam06 X-HE-Tag: 1680633868-518842 X-HE-Meta: U2FsdGVkX19VoUBi4ltCcYsLSsudsdlI1kfCpOIC7zINg9Z9GlGq3zLgcrMNmYECyeaC8BUSQqAmXyIKmg5ruc0CS2jz2Ooy8Kftck/5UWP033C0lCuIhjPSwOrjUpXjy1nuVyoflpwI07FnyuutQywW48hFe3+Gkvny2XPJbmQ/fOi8wAlNIy6bSnCrMV89PXqOdxU92SxpO7EbalJfIdWXOskaJfqI8HPAT9a2SymWdZ+ijccWmLE99zkJ6JIcfx5Dv7MxqHFUGzCPBKdiZoEfjh8Q443aoXE6fdq3hC2g9fFvbCTw7HVDkwPC0QW9N2FiEc3PnzUN33Z1H5o82zuthZ9s+sH2WF1q3ILukoGrHBoXQXIgC2WP06EHzPfxvkF3aI3BxkwilpD73TBBABk21cWPsDZ41AFCv+Un5UIWrebJ29e2Dl0fWNd1Lm0EbaGWeejFkDgMGhdf9IbpL3T/t24qK1Ucm+4Brpo1qMb/s53yRfd0uyvPzrwQHyf1P9Aqp4DByogIVBXUDKSsm+E4e3PH85uO6jQPSptyIosjNCqnOSx8zmFjxeGmjMhte28DlH13bf4u34IfaUw8EK/hHK3BvHFth2r5ujvcLMu1R8vqJd35QcKI1uV0ZP/8m+g98OKroQ1chdIxhrwOvw1hX2baS9HPdUo6x3W5Szkj8PKBo6XEO2rVP8hDcV6fzuInO6JIJKEK0hD1zSYASeGtlNhfgBGNZ70oIZ8zShhUXAl0jvsdO8jrxvMmCovtBsq2RiYKk/V0lj/mWGD0FpadxD20mluG2VEiGTtS8z+GeUNAS8svvk9LaRVxRZpn0P3CxTaXZ5y/jUc+iPzs+9+ggcR5OpW7Vw7PPuBM1AnT23tCBXIVOscLHqHSm6UtQMGTglzFo2lEDYjOhR/2/zW0KHKmQrNswCqGCWG9Ep4qXZqu40g7wyN+AfM4fIfIRtwz6VGDbaCSlt2BPUR a1lNhdQv Da9f4Vp0x8qInryl90dKqpaHMISVgffuWyqwDhE1OKPCQXcIJudMGiRhGmg6kdNaBQhk4yb/jFzoP5O2FofWng8yw9r+CV7T931qe6Hr9pEp52UUB4f/IblDyFys5KnnL0vkAeT8P7NBBJG/t9+eO5m92N+MIF+WOGkoAS5uAI7zqIV3beRe3+PuP/VyvFWFOFNxSbBp20iRuitLw5BK++GxNujS0BZI31B1SdQ4zV5VJIpcWIiHdZniTL++WBqrlpXLRUa6ROeqoOO8XXT0L0ehY2+NptgWy3uHacQk1P/f5mqxanKXtwSr2w1WS2nxtudgtfU9BnV3W9dTZG7wPZntMDD0vsNaVHcvUAx7HPm8urgj3uqE8Rz/mnjAziLeHQY/FcROm/7x6E+WsUNAm51G4icRSuvzNXvDvW9WcHrToWtR3zyfjQyBvr/7Ba5Xk1Z8aH5qegHSWYW/dE8C+Nkogx2+QQBlzjc0Jr8PIWV9zZ4YUJ1hjiWaFaBKPeJb6HjK8ULrvuAbKr1gMK3MnIx2UpjVvyAYHkH60 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: --000000000000ab659505f887105b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Friendly ping for review :) On Wed, Mar 29, 2023 at 8:11=E2=80=AFAM Jiaqi Yan wro= te: > Problem > =3D=3D=3D=3D=3D=3D=3D > Memory DIMMs are subject to multi-bit flips, i.e. memory errors. > As memory size and density increase, the chances of and number of > memory errors increase. The increasing size and density of server > RAM in the data center and cloud have shown increased uncorrectable > memory errors. There are already mechanisms in the kernel to recover > from uncorrectable memory errors. This series of patches provides > the recovery mechanism for the particular kernel agent khugepaged > when it collapses memory pages. > > Impact > =3D=3D=3D=3D=3D=3D > The main reason we chose to make khugepaged collapsing tolerant of > memory failures was its high possibility of accessing poisoned memory > while performing functionally optional compaction actions. > Standard applications typically don't have strict requirements on > the size of its pages. So they are given 4K pages by the kernel. > The kernel is able to improve application performance by either > > 1) giving applications 2M pages to begin with, or > 2) collapsing 4K pages into 2M pages when possible. > > This collapsing operation is done by khugepaged, a kernel agent that > is constantly scanning memory. When collapsing 4K pages into a 2M page, > it must copy the data from the 4K pages into a physically contiguous > 2M page. Therefore, as long as there exists one poisoned cache line in > collapsible 4K pages, khugepaged will eventually access it. The current > impact to users is a machine check exception triggered kernel panic. > However, khugepaged=E2=80=99s compaction operations are not functionally = required > kernel actions. Therefore making khugepaged tolerant to poisoned memory > will greatly improve user experience. > > This patch series is for cases where khugepaged is the first guy > that detects the memory errors on the poisoned pages. IOW, the pages > are not known to have memory errors when khugepaged collapsing gets to > them. In our observation, this happens frequently when the huge page > ratio of the system is relatively low, which is fairly common in > virtual machines running on cloud. > > Solution > =3D=3D=3D=3D=3D=3D=3D=3D > As stated before, it is less desirable to crash the system only because > khugepaged accesses poisoned pages while it is collapsing 4K pages. > The high level idea of this patch series is to skip the group of pages > (usually 512 4K-size pages) once khugepaged finds one of them is poisoned= , > as these pages have become ineligible to be collapsed. > > We are also careful to unwind operations khuagepaged has performed before > it detects memory failures. For example, before copying and collapsing > a group of anonymous pages into a huge page, the source pages will be > isolated and their page table is unlinked from their PMD. These operation= s > need to be undone in order to ensure these pages are not changed/lost fro= m > the perspective of other threads (both user and kernel space). As for > file backed memory pages, there already exists a rollback case. This > patch just extends it so that khugepaged also correctly rolls back when > it fails to copy poisoned 4K pages. > > Changelog > =3D=3D=3D=3D=3D=3D=3D=3D=3D > v12 changes > - Incorporate feedbacks from Shi Yang . > - Drop unused pmd from __collapse_huge_page_copy_succeeded. > - Drop unused address from __collapse_huge_page_copy_failed. > - smp_mb() should be after filemap_nr_thps_dec. > - This revision is rebased to mm-unstable at commit 9b175ce664d33 > ("mm: move free_area_empty() to mm/internal.h") > > v11 changes > - Incorporate feedbacks from Shi Yang and Hugh > Dickins > - Replace releasing pages for-loop with release_pte_pages in > __collapse_huge_page_copy_failed. > - Rename pte_ptl to ptl in __collapse_huge_page_copy_succeeded. > - Fix a bug in __collapse_huge_page_copy_succeeded: ptep_clear should be > used instead of pte_clear. > - Drop _address in __collapse_huge_page_copy_succeeded. > - Add smp_mb() before updating filemap_nr_thps_dec. > - Move `nr =3D thp_nr_pages()` closer to its references. > - Remove an unnecessary goto statement. > - This revision is rebased to mm-unstable at commit b4e1277ee31db > ("xtensa: reword ARCH_FORCE_MAX_ORDER prompt and help text") > > v10 changes > - Incorporate feedbacks from Kirill A. Shutemov > > - Refactor the 2nd loop (after the loop for copying memory) into 2 helper > functions, one for actions to take when copying succeeded, one for when > copying failed due to #MC. > - Use copy_mc_user_highpage for anonymous memory. > - Introduce copy_mc_highpage and use it for file-backed memory. > - Rename the original PMD from `rollback` to `orig_pmd`. > - Some minor changes in comments, e.g. `normal page` to `raw page`. > - This revision is rebased to mm-unstable at commit df3ae4347aff9 > ("dma-buf: system_heap: avoid reclaim for order 4") > > v9 changes > - Incorporate feedback from Andrew Morton > - Move copy_mc_highpage into khugepage.c as a static out-of-line > function copy_mc_page. > > v8 changes > - Incorporate feedbacks from Tony Luck > - Rename copy_highpage_mc to copy_mc_highpage. > - Update copy_mc_highpage with kmsan changes. > - Code style changes: > 1) copy_mc_highpage returns int as "copy" is an action and is consisten= t > with copy_mc_user_highpage. > 2) __collapse_huge_page_copy returns scan_result(int) and is consistent > with __collapse_huge_page_isolate/swapin. > 3) variables are declared in separate lines in collapse_file. > > v7 changes > - Fix a bug "KASAN: stack-out-of-bounds Read in collapse_file". After > copying all pages into the huge page, clear_highpage should use index > instead of page->index. > > v6 changes > - Address comments from Kirill Shutemov > - Rewrite __collapse_huge_page_copy to make rollback operations more > clear to its reader. > - Add detailed test steps in each commit message. > > v5 changes > - Rebase patches to mm-unstable at > commit ffb39098bf87 ("Merge tag 'linux-kselftest-kunit-6.1-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest"). > - Resolves conflicts with: > commit 2f55f070e5b8 ("mm/khugepaged: minor cleanup for collapse_file") > commit 1baec203b77c ("mm/khugepaged: try to free transhuge swapcache > when possible") > > v4 changes > - Incorporate feedbacks from Yang Shi > - Remove tracepoint for __collapse_huge_page_copy, just keep SCAN_COPY_MC > and let trace_mm_collapse_huge_page it > - Remove unnecessary comments > > v3 changes > - Incorporate feedbacks from Yang Shi > - Add tracepoint for __collapse_huge_page_copy > - Restore PMD in collapse_huge_page > - Correct comment about mmap_read_lock > > v2 changes > - Incorporate feedbacks from Yang Shi > - Only keep copy_highpage_mc > - Adding new scan_result SCAN_COPY_MC > - Defer NR_FILE_THPS update until copying succeeded > > Jiaqi Yan (3): > mm/khugepaged: recover from poisoned anonymous memory > mm/hwpoison: introduce copy_mc_highpage > mm/khugepaged: recover from poisoned file-backed memory > > include/linux/highmem.h | 54 ++++++-- > include/trace/events/huge_memory.h | 3 +- > mm/khugepaged.c | 200 ++++++++++++++++++++++------- > 3 files changed, 198 insertions(+), 59 deletions(-) > > -- > 2.40.0.348.gf938b09366-goog > > --000000000000ab659505f887105b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Friendly ping for review :)

On Wed, Mar 29, 2023 at 8:11=E2= =80=AFAM Jiaqi Yan <jiaqiyan@goog= le.com> wrote:
Problem
=3D=3D=3D=3D=3D=3D=3D
Memory DIMMs are subject to multi-bit flips, i.e. memory errors.
As memory size and density increase, the chances of and number of
memory errors increase. The increasing size and density of server
RAM in the data center and cloud have shown increased uncorrectable
memory errors. There are already mechanisms in the kernel to recover
from uncorrectable memory errors. This series of patches provides
the recovery mechanism for the particular kernel agent khugepaged
when it collapses memory pages.

Impact
=3D=3D=3D=3D=3D=3D
The main reason we chose to make khugepaged collapsing tolerant of
memory failures was its high possibility of accessing poisoned memory
while performing functionally optional compaction actions.
Standard applications typically don't have strict requirements on
the size of its pages. So they are given 4K pages by the kernel.
The kernel is able to improve application performance by either

=C2=A0 1) giving applications 2M pages to begin with, or
=C2=A0 2) collapsing 4K pages into 2M pages when possible.

This collapsing operation is done by khugepaged, a kernel agent that
is constantly scanning memory. When collapsing 4K pages into a 2M page,
it must copy the data from the 4K pages into a physically contiguous
2M page. Therefore, as long as there exists one poisoned cache line in
collapsible 4K pages, khugepaged will eventually access it. The current
impact to users is a machine check exception triggered kernel panic.
However, khugepaged=E2=80=99s compaction operations are not functionally re= quired
kernel actions. Therefore making khugepaged tolerant to poisoned memory
will greatly improve user experience.

This patch series is for cases where khugepaged is the first guy
that detects the memory errors on the poisoned pages. IOW, the pages
are not known to have memory errors when khugepaged collapsing gets to
them. In our observation, this happens frequently when the huge page
ratio of the system is relatively low, which is fairly common in
virtual machines running on cloud.

Solution
=3D=3D=3D=3D=3D=3D=3D=3D
As stated before, it is less desirable to crash the system only because
khugepaged accesses poisoned pages while it is collapsing 4K pages.
The high level idea of this patch series is to skip the group of pages
(usually 512 4K-size pages) once khugepaged finds one of them is poisoned,<= br> as these pages have become ineligible to be collapsed.

We are also careful to unwind operations khuagepaged has performed before it detects memory failures. For example, before copying and collapsing
a group of anonymous pages into a huge page, the source pages will be
isolated and their page table is unlinked from their PMD. These operations<= br> need to be undone in order to ensure these pages are not changed/lost from<= br> the perspective of other threads (both user and kernel space). As for
file backed memory pages, there already exists a rollback case. This
patch just extends it so that khugepaged also correctly rolls back when
it fails to copy poisoned 4K pages.

Changelog
=3D=3D=3D=3D=3D=3D=3D=3D=3D
v12 changes
- Incorporate feedbacks from Shi Yang <shy828301@gmail.com>.
- Drop unused pmd from __collapse_huge_page_copy_succeeded.
- Drop unused address from __collapse_huge_page_copy_failed.
- smp_mb() should be after filemap_nr_thps_dec.
- This revision is rebased to mm-unstable at commit 9b175ce664d33
=C2=A0 ("mm: move free_area_empty() to mm/internal.h")

v11 changes
- Incorporate feedbacks from Shi Yang <shy828301@gmail.com> and Hugh
=C2=A0 Dickins <hu= ghd@google.com>
- Replace releasing pages for-loop with release_pte_pages in
=C2=A0 __collapse_huge_page_copy_failed.
- Rename pte_ptl to ptl in __collapse_huge_page_copy_succeeded.
- Fix a bug in __collapse_huge_page_copy_succeeded: ptep_clear should be =C2=A0 used instead of pte_clear.
- Drop _address in __collapse_huge_page_copy_succeeded.
- Add smp_mb() before updating filemap_nr_thps_dec.
- Move `nr =3D thp_nr_pages()` closer to its references.
- Remove an unnecessary goto statement.
- This revision is rebased to mm-unstable at commit b4e1277ee31db
=C2=A0 ("xtensa: reword ARCH_FORCE_MAX_ORDER prompt and help text"= ;)

v10 changes
- Incorporate feedbacks from Kirill A. Shutemov
=C2=A0 <kirill.shutemov@linux.intel.com>
- Refactor the 2nd loop (after the loop for copying memory) into 2 helper =C2=A0 functions, one for actions to take when copying succeeded, one for w= hen
=C2=A0 copying failed due to #MC.
- Use copy_mc_user_highpage for anonymous memory.
- Introduce copy_mc_highpage and use it for file-backed memory.
- Rename the original PMD from `rollback` to `orig_pmd`.
- Some minor changes in comments, e.g. `normal page` to `raw page`.
- This revision is rebased to mm-unstable at commit df3ae4347aff9
=C2=A0 ("dma-buf: system_heap: avoid reclaim for order 4")

v9 changes
- Incorporate feedback from Andrew Morton <akpm@linux-foundation.org>
- Move copy_mc_highpage into khugepage.c as a static out-of-line
=C2=A0 function copy_mc_page.

v8 changes
- Incorporate feedbacks from Tony Luck <tony.luck@intel.com>
- Rename copy_highpage_mc to copy_mc_highpage.
- Update copy_mc_highpage with kmsan changes.
- Code style changes:
=C2=A0 1) copy_mc_highpage returns int as "copy" is an action and= is consistent
=C2=A0 =C2=A0 =C2=A0with copy_mc_user_highpage.
=C2=A0 2) __collapse_huge_page_copy returns scan_result(int) and is consist= ent
=C2=A0 =C2=A0 =C2=A0with __collapse_huge_page_isolate/swapin.
=C2=A0 3) variables are declared in separate lines in collapse_file.

v7 changes
- Fix a bug "KASAN: stack-out-of-bounds Read in collapse_file". A= fter
=C2=A0 copying all pages into the huge page, clear_highpage should use inde= x
=C2=A0 instead of page->index.

v6 changes
- Address comments from Kirill Shutemov <kirill@shutemov.name>
- Rewrite __collapse_huge_page_copy to make rollback operations more
=C2=A0 clear to its reader.
- Add detailed test steps in each commit message.

v5 changes
- Rebase patches to mm-unstable at
=C2=A0 commit ffb39098bf87 ("Merge tag 'linux-kselftest-kunit-6.1-= rc1' of
=C2=A0 git://git.kernel.org/pub/= scm/linux/kernel/git/shuah/linux-kselftest").
- Resolves conflicts with:
=C2=A0 commit 2f55f070e5b8 ("mm/khugepaged: minor cleanup for collapse= _file")
=C2=A0 commit 1baec203b77c ("mm/khugepaged: try to free transhuge swap= cache
=C2=A0 when possible")

v4 changes
- Incorporate feedbacks from Yang Shi <shy828301@gmail.com>
- Remove tracepoint for __collapse_huge_page_copy, just keep SCAN_COPY_MC =C2=A0 and let trace_mm_collapse_huge_page it
- Remove unnecessary comments

v3 changes
- Incorporate feedbacks from Yang Shi <shy828301@gmail.com>
- Add tracepoint for __collapse_huge_page_copy
- Restore PMD in collapse_huge_page
- Correct comment about mmap_read_lock

v2 changes
- Incorporate feedbacks from Yang Shi <shy828301@gmail.com>
- Only keep copy_highpage_mc
- Adding new scan_result SCAN_COPY_MC
- Defer NR_FILE_THPS update until copying succeeded

Jiaqi Yan (3):
=C2=A0 mm/khugepaged: recover from poisoned anonymous memory
=C2=A0 mm/hwpoison: introduce copy_mc_highpage
=C2=A0 mm/khugepaged: recover from poisoned file-backed memory

=C2=A0include/linux/highmem.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 54 ++++++--
=C2=A0include/trace/events/huge_memory.h |=C2=A0 =C2=A03 +-
=C2=A0mm/khugepaged.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | 200 ++++++++++++++++++++++-------
=C2=A03 files changed, 198 insertions(+), 59 deletions(-)

--
2.40.0.348.gf938b09366-goog

--000000000000ab659505f887105b--