From: Jiaqi Yan <jiaqiyan@google.com>
To: akpm@linux-foundation.org, mike.kravetz@oracle.com,
naoya.horiguchi@nec.com
Cc: songmuchun@bytedance.com, shy828301@gmail.com,
linmiaohe@huawei.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, duenwen@google.com,
axelrasmussen@google.com, jthoughton@google.com,
Jiaqi Yan <jiaqiyan@google.com>
Subject: [PATCH v3 0/4] Improve hugetlbfs read on HWPOISON hugepages
Date: Fri, 7 Jul 2023 20:19:00 +0000 [thread overview]
Message-ID: <20230707201904.953262-1-jiaqiyan@google.com> (raw)
Today when hardware memory is corrupted in a hugetlb hugepage,
kernel leaves the hugepage in pagecache [1]; otherwise future mmap or
read will suject to silent data corruption. This is implemented by
returning -EIO from hugetlb_read_iter immediately if the hugepage has
HWPOISON flag set.
Since memory_failure already tracks the raw HWPOISON subpages in a
hugepage, a natural improvement is possible: if userspace only asks for
healthy subpages in the pagecache, kernel can return these data.
This patchset implements this improvement. It consist of three parts.
The 1st commit exports the functionality to tell if a subpage inside a
hugetlb hugepage is a raw HWPOISON page. The 2nd commit teaches
hugetlbfs_read_iter to return as many healthy bytes as possible.
The 3rd commit properly tests this new feature.
[1] commit 8625147cafaa ("hugetlbfs: don't delete error page from pagecache")
Changelog
v2 => v3
* Updates commit messages for future reader to know background and
code details
* v3 is based on commit 5bb367dca2b9 ("Merge branch 'master' into
mm-stable")
v1 => v2
* __folio_free_raw_hwp deletes all entries in raw_hwp_list before it
traverses and frees raw_hwp_page.
* find_raw_hwp_page => __is_raw_hwp_subpage and __is_raw_hwp_subpage
only returns bool instead of a raw_hwp_page entry.
* is_raw_hwp_subpage holds hugetlb_lock while checking
__is_raw_hwp_subpage.
* No need to do folio_lock in adjust_range_hwpoison.
* v2 is based on commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM
GUP-fast writing to file-backed mappings")
Jiaqi Yan (4):
mm/hwpoison: delete all entries before traversal in
__folio_free_raw_hwp
mm/hwpoison: check if a subpage of a hugetlb folio is raw HWPOISON
hugetlbfs: improve read HWPOISON hugepage
selftests/mm: add tests for HWPOISON hugetlbfs read
fs/hugetlbfs/inode.c | 58 +++-
include/linux/hugetlb.h | 19 ++
include/linux/mm.h | 7 +
mm/hugetlb.c | 10 +
mm/memory-failure.c | 42 ++-
tools/testing/selftests/mm/.gitignore | 1 +
tools/testing/selftests/mm/Makefile | 1 +
.../selftests/mm/hugetlb-read-hwpoison.c | 322 ++++++++++++++++++
8 files changed, 439 insertions(+), 21 deletions(-)
create mode 100644 tools/testing/selftests/mm/hugetlb-read-hwpoison.c
--
2.41.0.255.g8b1d071c50-goog
next reply other threads:[~2023-07-07 20:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-07 20:19 Jiaqi Yan [this message]
2023-07-07 20:19 ` [PATCH v3 1/4] mm/hwpoison: delete all entries before traversal in __folio_free_raw_hwp Jiaqi Yan
2023-07-08 2:40 ` Miaohe Lin
2023-07-07 20:19 ` [PATCH v3 2/4] mm/hwpoison: check if a subpage of a hugetlb folio is raw HWPOISON Jiaqi Yan
2023-07-07 20:31 ` Matthew Wilcox
2023-07-07 21:05 ` Andrew Morton
2023-07-10 0:21 ` Naoya Horiguchi
2023-07-10 15:11 ` Jiaqi Yan
2023-07-11 8:59 ` Naoya Horiguchi
2023-07-08 2:57 ` Miaohe Lin
2023-07-10 15:16 ` Jiaqi Yan
2023-07-11 17:05 ` Jiaqi Yan
2023-07-11 18:01 ` Mike Kravetz
2023-07-11 22:22 ` Jiaqi Yan
2023-07-12 2:25 ` Miaohe Lin
2023-07-07 20:19 ` [PATCH v3 3/4] hugetlbfs: improve read HWPOISON hugepage Jiaqi Yan
2023-07-07 20:19 ` [PATCH v3 4/4] selftests/mm: add tests for HWPOISON hugetlbfs read Jiaqi Yan
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=20230707201904.953262-1-jiaqiyan@google.com \
--to=jiaqiyan@google.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=duenwen@google.com \
--cc=jthoughton@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=naoya.horiguchi@nec.com \
--cc=shy828301@gmail.com \
--cc=songmuchun@bytedance.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox