Re: [PATCH v6 0/2] kexec: keep the ne xt kernel off hardware-poisoned pages
Bradley Morgan <[email protected]>
| Newsgroups | org.infradead.lists.kexec,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 12 August 2026 12:31:50 BST, Breno Leitao <[email protected]> wrote: >Memory failures are common enough on large fleets that kexec regularly >lands the next kernel on a frame the memory failure subsystem has already >marked bad. Patch 2 teaches the segment placement to avoid those frames. > >Patch 1 is a prerequisite. locate_mem_hole_top_down() walks candidates >downwards without ever checking that the subtraction stays above zero, so >the walk can wrap and report success with a destination outside of RAM. >Patch 2 adds one more downward step to that loop, so the bug is fixed >first and both patches rely on the same bail-out. > >Signed-off-by: Breno Leitao <[email protected]> >--- >Changes in v6: >- Split the pre-existing top-down underflow out into its own patch, and > drop the "if (poison < kbuf->memsz)" guard from the hwpoison hunk now > that the loop bail-out covers it. (Mike Rapoport, Sashiko) >- Reword the changelog: the MCE comes from reading the poison back, not > from the relocation copy writing it, and the placement paragraphs read > better split up. (Mike Rapoport) >- Move cond_resched() after the struct page dereference, so the scan does > not yield between pfn_to_online_page() and is_page_hwpoison(). > (Pratyush Yadav, Sashiko) >- Keep cond_resched() per pfn rather than batching it. (Kiryl Shutsemau, > Rik van Riel) >- Link to v5: https://patch.msgid.link/[email protected] This is a two patch series with one patch, why? > >Changes in v5: >- Return -EHWPOISON instead of -EADDRNOTAVAIL >- Leverage is_page_hwpoison() instead of per-page check >- Link to v4: https://patch.msgid.link/[email protected] > >Changes in v4: >- Anchor the top-down hole finder on the first poisoned page in the > window and the bottom-up one on the last, so each jumps clear of the > poison in one step. New range_first_hwpoison(). (Kiryl Shutsemau) >- Count a poisoned hugetlb folio in full: the flag lives on the folio, > not on the subpages, so the per-pfn scan missed poisoned tail pages. > (Kiryl Shutsemau) >- Link to v3: https://patch.msgid.link/[email protected] > >Changes in v3: >- Return the address of the last poisoned page in the range, or > PHYS_ADDR_MAX when it is clean, instead of a bool plus an output > parameter. Renamed to range_last_hwpoison(). (Pratyush Yadav) >- Add cond_resched() to the scan loop, as a segment can span half of > memory. (Sashiko) >- Link to v2: https://patch.msgid.link/[email protected] > >Changes in v2: >- Change from pfn_to_page() to pfn_to_online_page(). (Miaohe Lin) >- Return the poisoned address once we find a hit, to avoid the O(n^2) > rescan. (Sashiko) >- Link to v1: https://patch.msgid.link/[email protected] > >To: Andrew Morton <[email protected]> >To: David Hildenbrand <[email protected]> >To: Lorenzo Stoakes <[email protected]> >To: "Liam R. Howlett" <[email protected]> >To: Vlastimil Babka <[email protected]> >To: Mike Rapoport <[email protected]> >To: Suren Baghdasaryan <[email protected]> >To: Michal Hocko <[email protected]> >To: Baoquan He <[email protected]> >To: Pasha Tatashin <[email protected]> >To: Pratyush Yadav <[email protected]> >To: Miaohe Lin <[email protected]> >To: Naoya Horiguchi <[email protected]> >Cc: [email protected] >Cc: [email protected] >Cc: [email protected] >Cc: [email protected] >Cc: [email protected] > >--- >Breno Leitao (2): > kexec_file: stop the top-down search before it underflows > kexec: keep the next kernel off hardware-poisoned pages > > include/linux/mm.h | 14 ++++++++++++++ > kernel/kexec_core.c | 10 ++++++++++ > kernel/kexec_file.c | 20 +++++++++++++++++++- > mm/memory-failure.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 83 insertions(+), 1 deletion(-) >--- >base-commit: c5e32e86ca02b003f86e095d379b38148999293d >change-id: 20260727-kexec_posioned-72bb0a4143a0 > >Best regards, >-- >Breno Leitao <[email protected]> > > Thanks!