From: Zi Yan <ziy@nvidia.com>
To: Usama Arif <usama.arif@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
apopple@nvidia.com, byungchul@sk.com, david@kernel.org,
gourry@gourry.net, jannh@google.com, joshua.hahnjy@gmail.com,
liam@infradead.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org,
matthew.brost@intel.com, mhocko@suse.com, pfalcato@suse.de,
rppt@kernel.org, surenb@google.com, vbabka@kernel.org,
ying.huang@linux.alibaba.com, kas@kernel.org, hannes@cmpxchg.org,
riel@surriel.com, shakeel.butt@linux.dev, kernel-team@meta.com,
baolin.wang@linux.alibaba.com, Nico Pache <nico.pache@linux.dev>,
ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org,
lance.yang@linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH 1/3] mm: don't PTE-batch a swap-in over a hardware-poisoned subpage
Date: Wed, 11 Nov 2026 13:50:29 -0500 [thread overview]
Message-ID: <2214E459-71AA-42FD-AAAD-07C49C81A676@nvidia.com> (raw)
In-Reply-To: <20261111113904.650722-2-usama.arif@linux.dev>
On 11 Nov 2026, at 6:38, Usama Arif wrote:
> do_swap_page() checks PageHWPoison() on the faulting page, but the
> large-folio batching path then maps the rest of the folio without looking
> at the other subpages. A poisoned subpage that is not the one being
> faulted gets mapped anyway, and the fault that would have reported it
> never happens.
>
> Skip batching for such a folio and let each page take its own fault,
> where the existing check catches it.
>
> Scan the subpages rather than testing the folio-level PG_has_hwpoisoned:
> memory_failure() sets PageHWPoison() on the subpage first and only sets
> the folio flag much later, and the bail-outs in between - for example
> get_hwpoison_page() losing a page lifecycle race - return with the
> subpage marked and the folio flag never set.
>
> Fixes: 508758960b8d ("mm: swap: entirely map large folios found in swapcache")
> Cc: stable@vger.kernel.org
> Signed-off-by: Usama Arif <usama.arif@linux.dev>
> ---
> mm/internal.h | 15 +++++++++++++++
> mm/memory.c | 4 ++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index cd3675c044e0a..e61c02f4019b0 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -28,6 +28,21 @@ struct folio_batch;
> int __copy_remote_mm_str(struct mm_struct *mm, unsigned long addr,
> void *buf, int len, unsigned int gup_flags);
>
> +/*
> + * Check every page of the folio for HWPoison, rather than relying on the
> + * folio-level PG_has_hwpoisoned, which memory_failure() can leave clear.
> + */
> +static inline bool folio_has_any_hwpoisoned_page(const struct folio *folio)
> +{
> + long nr = folio_nr_pages(folio);
> + long i;
> +
> + for (i = 0; i < nr; i++)
> + if (PageHWPoison(folio_page(folio, i)))
> + return true;
> + return false;
> +}
It looks almost the same as page_range_has_hwpoisoned() in mm/huge_memory.c.
Maybe change the function to call page_range_has_hwpoisoned() instead.
> +
> /* mm/workingset.c */
> bool workingset_test_recent(void *shadow, bool file, bool *workingset,
> bool flush);
> diff --git a/mm/memory.c b/mm/memory.c
> index d477a4f986bc8..4b7d456332200 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5158,6 +5158,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> swap_pte_batch(folio_ptep, nr, folio_pte) != nr)
> goto check_folio;
>
> + /* Let a poisoned subpage take its own fault. */
> + if (folio_has_any_hwpoisoned_page(folio))
> + goto check_folio;
> +
> page_idx = idx;
> address = folio_start;
> ptep = folio_ptep;
> --
> 2.53.0-Meta
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-11-11 18:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 11:38 [PATCH 0/3] mm: fixes for THP migration, swap-in and device-private smaps Usama Arif
2026-11-11 11:38 ` [PATCH 1/3] mm: don't PTE-batch a swap-in over a hardware-poisoned subpage Usama Arif
2026-11-11 13:18 ` Lorenzo Stoakes (ARM)
2026-11-11 18:39 ` Usama Arif
2026-11-11 18:50 ` Zi Yan [this message]
2026-11-11 11:38 ` [PATCH 2/3] fs/proc/task_mmu: don't read young/dirty from a non-present PMD in smaps Usama Arif
2026-11-11 13:27 ` Lorenzo Stoakes (ARM)
2026-11-11 11:38 ` [PATCH 3/3] fs/proc/task_mmu: account device-private PMDs as present " Usama Arif
2026-11-11 13:30 ` Lorenzo Stoakes (ARM)
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=2214E459-71AA-42FD-AAAD-07C49C81A676@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=nico.pache@linux.dev \
--cc=pfalcato@suse.de \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=ying.huang@linux.alibaba.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
all inboxes | Powered by JetHome®