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(-)
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 <leitao@debian.org>
---
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/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org
Changes in v5:
- Return -EHWPOISON instead of -EADDRNOTAVAIL
- Leverage is_page_hwpoison() instead of per-page check
- Link to v4: https://patch.msgid.link/20260807-kexec_posioned-v4-1-70d57f14625d@debian.org
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/20260803-kexec_posioned-v3-1-83aa6ede0351@debian.org
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/20260730-kexec_posioned-v2-1-f92d18551f64@debian.org
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/20260728-kexec_posioned-v1-1-160c81d180fe@debian.org
To: Andrew Morton <akpm@linux-foundation.org>
To: David Hildenbrand <david@kernel.org>
To: Lorenzo Stoakes <ljs@kernel.org>
To: "Liam R. Howlett" <liam@infradead.org>
To: Vlastimil Babka <vbabka@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
To: Michal Hocko <mhocko@suse.com>
To: Baoquan He <baoquan.he@linux.dev>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Pratyush Yadav <pratyush@kernel.org>
To: Miaohe Lin <linmiaohe@huawei.com>
To: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org
Cc: rmikey@meta.com
Cc: riel@surriel.com
---
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 <leitao@debian.org>
On Wed, Aug 12, 2026 at 04:31:50AM -0700, Breno Leitao 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. I queued this for v7.4, the patches will appear in the liveupdate tree after the merge window. > Signed-off-by: Breno Leitao <leitao@debian.org> > --- > 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/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org > > Changes in v5: > - Return -EHWPOISON instead of -EADDRNOTAVAIL > - Leverage is_page_hwpoison() instead of per-page check > - Link to v4: https://patch.msgid.link/20260807-kexec_posioned-v4-1-70d57f14625d@debian.org > > 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/20260803-kexec_posioned-v3-1-83aa6ede0351@debian.org > > 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/20260730-kexec_posioned-v2-1-f92d18551f64@debian.org > > 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/20260728-kexec_posioned-v1-1-160c81d180fe@debian.org > > To: Andrew Morton <akpm@linux-foundation.org> > To: David Hildenbrand <david@kernel.org> > To: Lorenzo Stoakes <ljs@kernel.org> > To: "Liam R. Howlett" <liam@infradead.org> > To: Vlastimil Babka <vbabka@kernel.org> > To: Mike Rapoport <rppt@kernel.org> > To: Suren Baghdasaryan <surenb@google.com> > To: Michal Hocko <mhocko@suse.com> > To: Baoquan He <baoquan.he@linux.dev> > To: Pasha Tatashin <pasha.tatashin@soleen.com> > To: Pratyush Yadav <pratyush@kernel.org> > To: Miaohe Lin <linmiaohe@huawei.com> > To: Naoya Horiguchi <nao.horiguchi@gmail.com> > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > Cc: kexec@lists.infradead.org > Cc: rmikey@meta.com > Cc: riel@surriel.com > > --- > 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 <leitao@debian.org> > -- Sincerely yours, Mike.
On 19 August 2026 10:36:17 BST, Mike Rapoport <rppt@kernel.org> wrote: >On Wed, Aug 12, 2026 at 04:31:50AM -0700, Breno Leitao 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. > >I queued this for v7.4, the patches will appear in the liveupdate tree >after the merge window. > Ah, so it'll appear in a maintainers tree after MW? >> Signed-off-by: Breno Leitao <leitao@debian.org> >> --- >> 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/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org >> >> Changes in v5: >> - Return -EHWPOISON instead of -EADDRNOTAVAIL >> - Leverage is_page_hwpoison() instead of per-page check >> - Link to v4: >https://patch.msgid.link/20260807-kexec_posioned-v4-1-70d57f14625d@debian.org >> >> 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/20260803-kexec_posioned-v3-1-83aa6ede0351@debian.org >> >> 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/20260730-kexec_posioned-v2-1-f92d18551f64@debian.org >> >> 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/20260728-kexec_posioned-v1-1-160c81d180fe@debian.org >> >> To: Andrew Morton <akpm@linux-foundation.org> >> To: David Hildenbrand <david@kernel.org> >> To: Lorenzo Stoakes <ljs@kernel.org> >> To: "Liam R. Howlett" <liam@infradead.org> >> To: Vlastimil Babka <vbabka@kernel.org> >> To: Mike Rapoport <rppt@kernel.org> >> To: Suren Baghdasaryan <surenb@google.com> >> To: Michal Hocko <mhocko@suse.com> >> To: Baoquan He <baoquan.he@linux.dev> >> To: Pasha Tatashin <pasha.tatashin@soleen.com> >> To: Pratyush Yadav <pratyush@kernel.org> >> To: Miaohe Lin <linmiaohe@huawei.com> >> To: Naoya Horiguchi <nao.horiguchi@gmail.com> >> Cc: linux-mm@kvack.org >> Cc: linux-kernel@vger.kernel.org >> Cc: kexec@lists.infradead.org >> Cc: rmikey@meta.com >> Cc: riel@surriel.com >> >> --- >> 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 <leitao@debian.org> >> > > Thanks!
On Wed, Aug 19, 2026 at 03:23:04PM +0100, Bradley Morgan wrote: > On 19 August 2026 10:36:17 BST, Mike Rapoport <rppt@kernel.org> wrote: > >On Wed, Aug 12, 2026 at 04:31:50AM -0700, Breno Leitao 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. > > > >I queued this for v7.4, the patches will appear in the liveupdate tree > >after the merge window. > > > > Ah, so it'll appear in a maintainers tree after MW? Yes > >> Signed-off-by: Breno Leitao <leitao@debian.org> > >> --- > >> 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/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org > >> > >> Changes in v5: > >> - Return -EHWPOISON instead of -EADDRNOTAVAIL > >> - Leverage is_page_hwpoison() instead of per-page check > >> - Link to v4: > >https://patch.msgid.link/20260807-kexec_posioned-v4-1-70d57f14625d@debian.org > >> > >> 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/20260803-kexec_posioned-v3-1-83aa6ede0351@debian.org > >> > >> 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/20260730-kexec_posioned-v2-1-f92d18551f64@debian.org > >> > >> 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/20260728-kexec_posioned-v1-1-160c81d180fe@debian.org > >> > >> To: Andrew Morton <akpm@linux-foundation.org> > >> To: David Hildenbrand <david@kernel.org> > >> To: Lorenzo Stoakes <ljs@kernel.org> > >> To: "Liam R. Howlett" <liam@infradead.org> > >> To: Vlastimil Babka <vbabka@kernel.org> > >> To: Mike Rapoport <rppt@kernel.org> > >> To: Suren Baghdasaryan <surenb@google.com> > >> To: Michal Hocko <mhocko@suse.com> > >> To: Baoquan He <baoquan.he@linux.dev> > >> To: Pasha Tatashin <pasha.tatashin@soleen.com> > >> To: Pratyush Yadav <pratyush@kernel.org> > >> To: Miaohe Lin <linmiaohe@huawei.com> > >> To: Naoya Horiguchi <nao.horiguchi@gmail.com> > >> Cc: linux-mm@kvack.org > >> Cc: linux-kernel@vger.kernel.org > >> Cc: kexec@lists.infradead.org > >> Cc: rmikey@meta.com > >> Cc: riel@surriel.com > >> > >> --- > >> 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 <leitao@debian.org> > >> > > > > > > Thanks! -- Sincerely yours, Mike.
On Wed, Aug 19, 2026 at 12:36:17PM +0300, Mike Rapoport wrote: > On Wed, Aug 12, 2026 at 04:31:50AM -0700, Breno Leitao 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. > > I queued this for v7.4, the patches will appear in the liveupdate tree > after the merge window. Thanks Mike. I'll now get back to the most ambicious patchset that carries poisoned page information over to the next kernel, so memory failure information survive across kexec: https://lore.kernel.org/all/20260717-hwpoison-kho-v1-0-9c5eda551998@debian.org/
On 12 August 2026 12:31:50 BST, Breno Leitao <leitao@debian.org> 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 <leitao@debian.org> >--- >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/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org 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/20260807-kexec_posioned-v4-1-70d57f14625d@debian.org > >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/20260803-kexec_posioned-v3-1-83aa6ede0351@debian.org > >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/20260730-kexec_posioned-v2-1-f92d18551f64@debian.org > >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/20260728-kexec_posioned-v1-1-160c81d180fe@debian.org > >To: Andrew Morton <akpm@linux-foundation.org> >To: David Hildenbrand <david@kernel.org> >To: Lorenzo Stoakes <ljs@kernel.org> >To: "Liam R. Howlett" <liam@infradead.org> >To: Vlastimil Babka <vbabka@kernel.org> >To: Mike Rapoport <rppt@kernel.org> >To: Suren Baghdasaryan <surenb@google.com> >To: Michal Hocko <mhocko@suse.com> >To: Baoquan He <baoquan.he@linux.dev> >To: Pasha Tatashin <pasha.tatashin@soleen.com> >To: Pratyush Yadav <pratyush@kernel.org> >To: Miaohe Lin <linmiaohe@huawei.com> >To: Naoya Horiguchi <nao.horiguchi@gmail.com> >Cc: linux-mm@kvack.org >Cc: linux-kernel@vger.kernel.org >Cc: kexec@lists.infradead.org >Cc: rmikey@meta.com >Cc: riel@surriel.com > >--- >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 <leitao@debian.org> > > Thanks!
Hello Bradley, On Wed, Aug 12, 2026 at 12:36:59PM +0100, Bradley Morgan wrote: > On 12 August 2026 12:31:50 BST, Breno Leitao <leitao@debian.org> wrote: > >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) <snip> > >- Link to v5: https://patch.msgid.link/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org > > This is a two patch series with one patch, why? This is a patch series with _two_ patches, isn't it? [PATCH v6 1/2] kexec_file: stop the top-down search before it underflows [PATCH v6 2/2] kexec: keep the next kernel off hardware-poisoned pages If you asking why it was split, we decided to split the fix into a separate patch, and keep the "feature" in separate patch. The discussion happened in https://lore.kernel.org/all/anskyrEVUlnTVEgF@kernel.org/
On 12 August 2026 13:07:49 BST, Breno Leitao <leitao@debian.org> wrote: >Hello Bradley, > >On Wed, Aug 12, 2026 at 12:36:59PM +0100, Bradley Morgan wrote: >> On 12 August 2026 12:31:50 BST, Breno Leitao <leitao@debian.org> wrote: >> >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) > ><snip> > >> >- Link to v5: >https://patch.msgid.link/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org >> >> This is a two patch series with one patch, why? > >This is a patch series with _two_ patches, isn't it? > > [PATCH v6 1/2] kexec_file: stop the top-down search before it underflows > [PATCH v6 2/2] kexec: keep the next kernel off hardware-poisoned pages > >If you asking why it was split, we decided to split the fix into >a separate patch, and keep the "feature" in separate patch. The >discussion happened in > I'm only CCed in 2/2 :( >https://lore.kernel.org/all/anskyrEVUlnTVEgF@kernel.org/ > Thanks!
© 2016 - 2026 Red Hat, Inc.