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

[David Hildenbrand (Arm)]

On 7/1/26 10:18, Michael S. Tsirkin wrote:
> On Wed, Jul 01, 2026 at 10:08:45AM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> Yay. I did that + dropped the extra lock/unlock and now it's in the noise in
>>> my testing. needs much more testing of course.
>>
>> Cool. I'd expect that latency-sensitive workloads (PREEMPT_RT) would not want to
>> have hwpoison handling either way, so using the no_resched variants at these
>> places might be doable.
>>
>>>
>>> If you want me to post (including addressing your other feedback) let me
>>> know.
>>>
>>
>> Let's first discuss the options. We essentially have the following one so far:
>>
>> 1) Ignore the problem
>>
>> It's been there forever ... but I am not quite happy about that.
>>
>> 2) Use atomics everywhere
>>
>> The easiest+cleanest, but as measured, the performance hit is real.
>>
>> 3) Keep retrying for a couple of times
>>
>> The big problem is "how long". A CPU in a hypervisor might be stalled for quite
>> a while (20s? can be longer).
> 
> So on this idea. It might not matter. What I had in mind is:
> 1. run the current logic
> 2. add page to a list of pages to check, then invoke e.g. call_rcu_tasks
>    (or call_rcu_tasks_rude) maybe
> 3. in the callback, recheck and if poison cleared, go back to 1
> 4. otherwise everyone will see the bit set, remove from list we are done
> 
> it seems to not regress anything, and for the rare race, we set
> the bit eventually.
> 

So test-and-set (and friends) would also have to check the data structure that
remembers bit to set/clear (and possibly update the data structure).

That does seem doable. Do you have a prototype?

-- 
Cheers,

David