Re: [PATCH RFC 1/1] mm/ksm: Add recovery mechanism for memory failures

[David Hildenbrand <david@redhat.com>]

On 13.10.25 13:00, Lance Yang wrote:
> 
> 
> On 2025/10/13 17:25, David Hildenbrand wrote:
>> On 13.10.25 11:15, Lance Yang wrote:
>>> @David
>>>
>>> Cc: MM CORE folks
>>>
>>> On 2025/10/13 12:42, Lance Yang wrote:
>>> [...]
>>>
>>> Cool. Hardware error injection with EINJ was the way to go!
>>>
>>> I just ran some tests on the shared zero page (both regular and huge),
>>> and
>>> found a tricky behavior:
>>>
>>> 1) When a hardware error is injected into the zeropage, the process that
>>> attempts to read from a mapping backed by it is correctly killed with a
>>> SIGBUS.
>>>
>>> 2) However, even after the error is detected, the kernel continues to
>>> install
>>> the known-poisoned zeropage for new anonymous mappings ...
>>>
>>>
>>> For the shared zeropage:
>>> ```
>>> [Mon Oct 13 16:29:02 2025] mce: Uncorrected hardware memory error in
>>> user-access at 29b8cf5000
>>> [Mon Oct 13 16:29:02 2025] Memory failure: 0x29b8cf5: Sending SIGBUS to
>>> read_zeropage:13767 due to hardware memory corruption
>>> [Mon Oct 13 16:29:02 2025] Memory failure: 0x29b8cf5: recovery action
>>> for already poisoned page: Failed
>>> ```
>>> And for the shared huge zeropage:
>>> ```
>>> [Mon Oct 13 16:35:34 2025] mce: Uncorrected hardware memory error in
>>> user-access at 1e1e00000
>>> [Mon Oct 13 16:35:34 2025] Memory failure: 0x1e1e00: Sending SIGBUS to
>>> read_huge_zerop:13891 due to hardware memory corruption
>>> [Mon Oct 13 16:35:34 2025] Memory failure: 0x1e1e00: recovery action for
>>> already poisoned page: Failed
>>> ```
>>>
>>> Since we've identified an uncorrectable hardware error on such a
>>> critical,
>>> singleton page, should we be doing something more?
>>
>> I mean, regarding the shared zeropage, we could try walking all page
>> tables of all processes and replace it be a fresh shared zeropage.
>>
>> But then, the page might also be used for other things (I/O etc), the
>> shared zeropage is allocated by the architecture, we'd have to make
>> is_zero_pfn() succeed on the old+new page etc ...
>>
>> So a lot of work for little benefit I guess? The question is how often
>> we would see that in practice. I'd assume we'd see it happen on random
>> kernel memory more frequently where we can really just bring down the
>> whole machine.
> 
> Thanks for your thoughts!
> 
> I agree, fixing the regular zeropage is a really mess ...
> 
> But for the huge zeropage, what if we just stop installing it once it's
> poisoned? We could just disable it globally. Something like this:

We now have the static huge zero folio that could silently be used for 
I/O without a reference etc.

So I'm afraid this is all just making corner cases slightly better.

-- 
Cheers

David / dhildenb