Re: [PATCH 0/2] mm: memory-failure: fix HWPoison flag race with non-atomic page flag ops

[David Hildenbrand (Arm)]

On 7/8/26 15:08, Michael S. Tsirkin wrote:
> On Wed, Jul 08, 2026 at 02:03:21PM +0200, David Hildenbrand (Arm) wrote:
>> On 7/7/26 22:27, Michael S. Tsirkin wrote:
>>>
>>> I spent a bit poking at it, and it's hairy.
>>
>> What I thought ...
>>
>>> The issue is that we have calls to both set and clear bits.
>>> When we record them in a side side structure so they can be retried,
>>> we have to carefully record both sets and clears and their order and make sure
>>> they do not bypass each other. So if there's set already in the
>>> structure, we need to take it out of structure and only then add a clear.
>>>
>>> It gets very hairy because we want to set from NMI.  So now we can have
>>> clear in the data structure and set from NMI bypasses that. Now what?
>>> And set from NMI can't be 100% safe anyway as we discussed ...  Kinda
>>> reduced my motivation to try and make this reliable at all.
>>
>> Maybe we should just really keep it as broken as it currently is. It's not
>> really worth our time fixing basic design flaws ... given that we didn't have
>> any report about these races so far :/
>>
>> I mean, sure, if it's easy, ... but it sounds like getting more and more complex.
>>
>> -- 
>> Cheers,
>>
>> David
> 
> Right. Either we do the RCU thing or let it be. But then I'm uninclined
> to even bother with fixing other weird behaviour I see there.

Yes, let's keep it as broken as it is for now, just not breaking it even more.
We discovered other hwpoison oddities lately, and decided that there needs to be
a high level discussion on a better design of hwpoion handling in general. It's
really just slapped on.

The page->flag handling is only a temporary concern, in some memdesc future the
problem will look differently, and likely easier to sort out..

-- 
Cheers,

David