From: Naoya Horiguchi <naoya.horiguchi@linux.dev>
To: Yang Shi <shy828301@gmail.com>
Cc: naoya.horiguchi@nec.com, hughd@google.com,
kirill.shutemov@linux.intel.com, willy@infradead.org,
peterx@redhat.com, osalvador@suse.de, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [v4 PATCH 2/6] mm: filemap: check if THP has hwpoisoned subpage for PMD page fault
Date: Tue, 19 Oct 2021 14:50:53 +0900 [thread overview]
Message-ID: <20211019055053.GA2268449@u2004> (raw)
In-Reply-To: <20211014191615.6674-3-shy828301@gmail.com>
On Thu, Oct 14, 2021 at 12:16:11PM -0700, Yang Shi wrote:
> When handling shmem page fault the THP with corrupted subpage could be PMD
> mapped if certain conditions are satisfied. But kernel is supposed to
> send SIGBUS when trying to map hwpoisoned page.
>
> There are two paths which may do PMD map: fault around and regular fault.
>
> Before commit f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() codepaths")
> the thing was even worse in fault around path. The THP could be PMD mapped as
> long as the VMA fits regardless what subpage is accessed and corrupted. After
> this commit as long as head page is not corrupted the THP could be PMD mapped.
>
> In the regular fault path the THP could be PMD mapped as long as the corrupted
> page is not accessed and the VMA fits.
>
> This loophole could be fixed by iterating every subpage to check if any
> of them is hwpoisoned or not, but it is somewhat costly in page fault path.
>
> So introduce a new page flag called HasHWPoisoned on the first tail page. It
> indicates the THP has hwpoisoned subpage(s). It is set if any subpage of THP
> is found hwpoisoned by memory failure and after the refcount is bumped
> successfully, then cleared when the THP is freed or split.
>
> The soft offline path doesn't need this since soft offline handler just
> marks a subpage hwpoisoned when the subpage is migrated successfully.
> But shmem THP didn't get split then migrated at all.
>
> Fixes: 800d8c63b2e9 ("shmem: add huge pages support")
> Cc: <stable@vger.kernel.org>
> Suggested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Signed-off-by: Yang Shi <shy828301@gmail.com>
> ---
> include/linux/page-flags.h | 23 +++++++++++++++++++++++
> mm/huge_memory.c | 2 ++
> mm/memory-failure.c | 14 ++++++++++++++
> mm/memory.c | 9 +++++++++
> mm/page_alloc.c | 4 +++-
> 5 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index a558d67ee86f..901723d75677 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -171,6 +171,15 @@ enum pageflags {
> /* Compound pages. Stored in first tail page's flags */
> PG_double_map = PG_workingset,
>
> +#ifdef CONFIG_MEMORY_FAILURE
> + /*
> + * Compound pages. Stored in first tail page's flags.
> + * Indicates that at least one subpage is hwpoisoned in the
> + * THP.
> + */
> + PG_has_hwpoisoned = PG_mappedtodisk,
> +#endif
> +
> /* non-lru isolated movable page */
> PG_isolated = PG_reclaim,
>
> @@ -668,6 +677,20 @@ PAGEFLAG_FALSE(DoubleMap)
> TESTSCFLAG_FALSE(DoubleMap)
> #endif
>
> +#if defined(CONFIG_MEMORY_FAILURE) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
> +/*
> + * PageHasHWPoisoned indicates that at least on subpage is hwpoisoned in the
At least "one" subpage?
> + * compound page.
> + *
> + * This flag is set by hwpoison handler. Cleared by THP split or free page.
> + */
> +PAGEFLAG(HasHWPoisoned, has_hwpoisoned, PF_SECOND)
> + TESTSCFLAG(HasHWPoisoned, has_hwpoisoned, PF_SECOND)
> +#else
> +PAGEFLAG_FALSE(HasHWPoisoned)
> + TESTSCFLAG_FALSE(HasHWPoisoned)
> +#endif
> +
> /*
> * Check if a page is currently marked HWPoisoned. Note that this check is
> * best effort only and inherently racy: there is no way to synchronize with
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 5e9ef0fc261e..0574b1613714 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2426,6 +2426,8 @@ static void __split_huge_page(struct page *page, struct list_head *list,
> /* lock lru list/PageCompound, ref frozen by page_ref_freeze */
> lruvec = lock_page_lruvec(head);
>
> + ClearPageHasHWPoisoned(head);
> +
> for (i = nr - 1; i >= 1; i--) {
> __split_huge_page_tail(head, i, lruvec, list);
> /* Some pages can be beyond EOF: drop them from page cache */
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 73f68699e7ab..2809d12f16af 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1694,6 +1694,20 @@ int memory_failure(unsigned long pfn, int flags)
> }
>
> if (PageTransHuge(hpage)) {
> + /*
> + * The flag must be set after the refcount is bumpped
s/bumpped/bumped/ ?
> + * otherwise it may race with THP split.
> + * And the flag can't be set in get_hwpoison_page() since
> + * it is called by soft offline too and it is just called
> + * for !MF_COUNT_INCREASE. So here seems to be the best
> + * place.
> + *
> + * Don't need care about the above error handling paths for
> + * get_hwpoison_page() since they handle either free page
> + * or unhandlable page. The refcount is bumpped iff the
There's another "bumpped".
Otherwise looks good to me.
Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
> + * page is a valid handlable page.
> + */
> + SetPageHasHWPoisoned(hpage);
> if (try_to_split_thp_page(p, "Memory Failure") < 0) {
> action_result(pfn, MF_MSG_UNSPLIT_THP, MF_IGNORED);
> res = -EBUSY;
> diff --git a/mm/memory.c b/mm/memory.c
> index adf9b9ef8277..c52be6d6b605 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3906,6 +3906,15 @@ vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
> if (compound_order(page) != HPAGE_PMD_ORDER)
> return ret;
>
> + /*
> + * Just backoff if any subpage of a THP is corrupted otherwise
> + * the corrupted page may mapped by PMD silently to escape the
> + * check. This kind of THP just can be PTE mapped. Access to
> + * the corrupted subpage should trigger SIGBUS as expected.
> + */
> + if (unlikely(PageHasHWPoisoned(page)))
> + return ret;
> +
> /*
> * Archs like ppc64 need additional space to store information
> * related to pte entry. Use the preallocated table for that.
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b37435c274cf..7f37652f0287 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1312,8 +1312,10 @@ static __always_inline bool free_pages_prepare(struct page *page,
>
> VM_BUG_ON_PAGE(compound && compound_order(page) != order, page);
>
> - if (compound)
> + if (compound) {
> ClearPageDoubleMap(page);
> + ClearPageHasHWPoisoned(page);
> + }
> for (i = 1; i < (1 << order); i++) {
> if (compound)
> bad += free_tail_pages_check(page, page + i);
> --
> 2.26.2
>
next prev parent reply other threads:[~2021-10-19 5:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-14 19:16 [RFC v4 PATCH 0/6] Solve silent data loss caused by poisoned page cache (shmem/tmpfs) Yang Shi
2021-10-14 19:16 ` [v4 PATCH 1/6] mm: hwpoison: remove the unnecessary THP check Yang Shi
2021-10-14 19:16 ` [v4 PATCH 2/6] mm: filemap: check if THP has hwpoisoned subpage for PMD page fault Yang Shi
2021-10-19 5:50 ` Naoya Horiguchi [this message]
2021-10-19 17:13 ` Yang Shi
2021-10-14 19:16 ` [v4 PATCH 3/6] mm: filemap: coding style cleanup for filemap_map_pmd() Yang Shi
2021-10-19 5:51 ` Naoya Horiguchi
2021-10-14 19:16 ` [v4 PATCH 4/6] mm: hwpoison: refactor refcount check handling Yang Shi
2021-10-14 19:16 ` [v4 PATCH 5/6] mm: shmem: don't truncate page if memory failure happens Yang Shi
2021-10-19 5:52 ` Naoya Horiguchi
2021-10-19 17:29 ` Yang Shi
2021-10-19 22:30 ` Naoya Horiguchi
2021-10-20 18:32 ` Yang Shi
2021-10-14 19:16 ` [v4 PATCH 6/6] mm: hwpoison: handle non-anonymous THP correctly Yang Shi
2021-10-15 20:28 ` [RFC v4 PATCH 0/6] Solve silent data loss caused by poisoned page cache (shmem/tmpfs) Andrew Morton
2021-10-15 21:48 ` Yang Shi
2021-10-19 5:53 ` Naoya Horiguchi
2021-10-19 17:32 ` Yang Shi
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=20211019055053.GA2268449@u2004 \
--to=naoya.horiguchi@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=shy828301@gmail.com \
--cc=willy@infradead.org \
/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.