Re: [PATCH v2 0/2] mm: don't migrate folios containing hwpoisoned pages

["David Hildenbrand (Arm)" <david@kernel.org>]

On 10/26/26 03:55, Yuanhe Shu wrote:
> v2 of this series.  No changes to the approach; the two deltas are a
> wording correction promised in the v1 discussion and a third check
> suggested by Kaitao Cheng.
> 
> memory_failure() can end up abandoning a folio while PG_hwpoison is
> already set on it.  Two ways to get there:
> 
>   1. Race: any isolator (compaction, NUMA balancing, move_pages(),
>      mbind(), CMA, long-term GUP) clears PG_lru from under
>      memory_failure(), which then fails the HWPoisonHandlable()
>      check, exhausts the get_any_page() retries and bails out with
>      MF_IGNORED - without holding any reference, but with the flag
>      set.
> 
>   2. No race at all: the THP-split-failure path
>      (kill_procs_now() + MF_MSG_UNSPLIT_THP) leaves a large folio
>      on the LRU with a PG_hwpoisoned subpage by design.
> 
> In both cases the migrator still holds the folio on its migration
> list and migrates it like any other: the corrupted data is copied
> into a fresh folio with no poison marker, and no hwpoison PTE entry
> is installed on the way back, so the userspace mapping is silently
> redirected to the corrupted copy - no SIGBUS is ever delivered.
> 
> This was reproduced on v7.3-rc4-75-g62f4c998b297 (the base of
> this series): an order-0 stress workload (madvise(MADV_HWPOISON)
> racing move_pages()) left the poison flag set on 8426 abandoned
> folios in a 180-second run; 698 of them were subsequently
> migrated, and in every case the address then served the copied
> corrupted data with no SIGBUS.  With patch 2, 0 of 9711 were
> propagated.
> 
> The compaction-side guard is needed regardless of how the race in
> memory_failure() itself might be addressed: the steady state
> (split failure leaves the folio on the LRU with the flag already
> set) is not a race at all.  Deterministically validated 16/16
> poisoned mTHP folios migrated unpatched vs 0/16 with patch 1,
> with clean controls migrating 16/16 in both runs.
> 
> The checks compose with, not replace, copy_mc: folio_mc_copy()
> still catches real-DRAM corruption during the copy on archs that
> implement it, and the flag checks refuse software-injected poison
> on all archs before and after the copy.  Extending the
> !ARCH_HAS_COPY_MC fallbacks of copy_mc_user_highpage() and
> copy_mc_highpage() with the same flag check - which would also
> cover their non-migration callers - was proposed by Huang, Ying
> and welcomed by David in the v1 discussion; that is posted as a
> separate patch right after this series.

With that patch in place, why do we still need these changes here?

-- 
Cheers,

David