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

[Michael S. Tsirkin]

On Wed, Jul 01, 2026 at 10:26:26AM +0200, David Hildenbrand (Arm) wrote:
> 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?

what do you think ;) post it?

> -- 
> Cheers,
> 
> David