From: Jane Chu <jane.chu@oracle.com>
To: linmiaohe@huawei.com, nao.horiguchi@gmail.com,
akpm@linux-foundation.org, osalvador@suse.de, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/5] Enhance soft hwpoison handling and injection
Date: Tue, 21 May 2024 17:54:24 -0600 [thread overview]
Message-ID: <20240521235429.2368017-1-jane.chu@oracle.com> (raw)
Changes in v3:
- rebased to mainline as of 5/20/2024
- added an acked-by from Miaohe Lin
- picked up a R-B from Oscar Salvador
- fixed/clarified comments about MF_IGNORED/MF_FAILED definition and
usage. - Oscar Salvador
- invoke hwpoison_filter slightly earlier to avoid unnecessary THP split,
and with refcount held. - Miaohe Lin
- added comments to try_to_split_thp_page() on when not to release page
refcount. - Oscar Salvador
- added action_result() in a couple cases, but take care not to overwrite
the intended returns. - Oscar Salvador
Changes in v2:
- rebased to mm-stable as of 5/8/2024
- added RB by Oscar Salvador
- comments from Oscar on patch 1-of-3: clarify changelog
- comments from Miahe Lin on patch 3-of-3: remove unnecessary user page
checking and remove incorrect put_page() in kill_procs_now().
Invoke kill_procs_now() regardless MF_ACTIN_REQUIRED is set or not,
moved hwpoison_filter() higher up.
- added two patches 3-of-5 and 4-of-5
This series aim at the following enhancement -
- Let one hwpoison injector, that is, madvise(MADV_HWPOISON) to behave
more like as if a real UE occurred. Because the other two injectors
such as hwpoison-inject and the 'einj' on x86 can't, and it seems to
me we need a better simulation to real UE scenario.
- For years, if the kernel is unable to unmap a hwpoisoned page, it send
a SIGKILL instead of SIGBUS to prevent user process from potentially
accessing the page again. But in doing so, the user process also lose
important information: vaddr, for recovery. Fortunately, the kernel
already has code to kill process re-accessing a hwpoisoned page, so
remove the '!unmap_success' check.
- Right now, if a thp page under GUP longterm pin is hwpoisoned, and
kernel cannot split the thp page, memory-failure simply ignores
the UE and returns. That's not ideal, it could deliver a SIGBUS with
useful information for userspace recovery.
Jane Chu (5):
mm/memory-failure: try to send SIGBUS even if unmap failed
mm/madvise: Add MF_ACTION_REQUIRED to madvise(MADV_HWPOISON)
mm/memory-failure: improve memory failure action_result messages
mm/memory-failure: move hwpoison_filter() higher up
mm/memory-failure: send SIGBUS in the event of thp split fail
include/linux/mm.h | 2 +
include/ras/ras_event.h | 2 +
mm/madvise.c | 2 +-
mm/memory-failure.c | 108 +++++++++++++++++++++++++++++-----------
4 files changed, 84 insertions(+), 30 deletions(-)
--
2.39.3
next reply other threads:[~2024-05-21 23:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 23:54 Jane Chu [this message]
2024-05-21 23:54 ` [PATCH v3 1/5] mm/memory-failure: try to send SIGBUS even if unmap failed Jane Chu
2024-05-21 23:54 ` [PATCH v3 2/5] mm/madvise: Add MF_ACTION_REQUIRED to madvise(MADV_HWPOISON) Jane Chu
2024-05-23 1:54 ` Miaohe Lin
2024-05-21 23:54 ` [PATCH v3 3/5] mm/memory-failure: improve memory failure action_result messages Jane Chu
2024-05-22 20:37 ` Oscar Salvador
2024-05-23 17:38 ` Jane Chu
2024-05-23 2:31 ` Miaohe Lin
2024-05-23 19:58 ` Jane Chu
2024-05-21 23:54 ` [PATCH v3 4/5] mm/memory-failure: move hwpoison_filter() higher up Jane Chu
2024-05-22 20:50 ` Oscar Salvador
2024-05-23 2:37 ` Miaohe Lin
2024-05-21 23:54 ` [PATCH v3 5/5] mm/memory-failure: send SIGBUS in the event of thp split fail Jane Chu
2024-05-22 20:57 ` Oscar Salvador
2024-05-23 3:02 ` Miaohe Lin
2024-05-23 20:01 ` Jane Chu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240521235429.2368017-1-jane.chu@oracle.com \
--to=jane.chu@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.