Re: [PATCH v5 0/9] mm/memory-failure: keep hardware-poisoned pages out of the next kexec

[Breno Leitao <leitao@debian.org>]

On Tue, Sep 22, 2026 at 05:29:14PM +0800, Miaohe Lin wrote:
> On 2026/9/22 17:14, Breno Leitao wrote:
> > Hello Miaohe,
> > 
> > On Tue, Sep 22, 2026 at 02:27:59PM +0800, Miaohe Lin wrote:
> >>> A bit is never cleared, which is a known limitation: it stands for a
> >>> whole unit, so an unpoison of one frame cannot tell whether the unit as a
> >>> whole is good again.
> >>
> >> Thanks for your patches. I have a question about unpoison: If a bit is never
> >> cleared, after we do some memory-failure+unpoison tests, kexec will lose the
> >> tested memory without reboot?
> > 
> > Correct, A bit stands for a 2M unit, so every tested page that falls in
> > a distinct unit costs 2M in each kernel after the kexec.
> > 
> > Worth being precise about the state today: the unpoison itself works.
> > The frame goes back to the allocator and num_poisoned_pages drops. Only
> > the bit stays, so the next kernel poisons the frame again. Test loop
> > in, memory out, and nothing gives it back.
> > 
> > Important to say that nothing block us from unpoison the bitmap, and in
> > fact my initial patchset had it. I also _think_ we should unpoison the
> > bitmap once we unpoison the page. 
> > 
> > I have just kept it out of this patch in order to simplify the patchset and
> > get the basis correct, and then evolve on top of it.
> > 
> 
> Makes sense to me. Thanks for your work.

Ack. I will continue it without the unpoisioned bits for now, and as
soon as this series lands, I will add the unpoision mechanism on top of
this infrastructure.

Thanks for your support so far. I will send a new version soon, with
the fixes I am accumulating so far.

--breno