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

[Michael S. Tsirkin]

On Mon, Jun 29, 2026 at 11:43:32PM +0200, David Hildenbrand (Arm) wrote:
> On 6/29/26 23:22, David Hildenbrand (Arm) wrote:
> > [...]
> > 
> >>
> >> And again, I'm really not sure fixing a theoretical race when memory
> >> is failing is worth slowing the world by 0.1-1% for.
> >>
> > 
> > Fully agreed. I was hoping RCU was cheaper (I mean, we were once told that RCU
> > read side locking is essentially for free ... well in some configs :) )
> > 
> > The question if we could optimize it reasonably enough ...
> > 
> >>
> >> From what I saw in my testing, if we allocate 4k pages
> >> it's hidden by the overhead. With hp and thp it's measureably
> >> worse than rcu on !preempt config.
> > 
> > ... for example, by doing the rcu read lock + unlock around the
> > 
> > 	for (i = 1; i < (1 << order); i++) {
> > 
> > loop on the alloc path. But I suspect it's not going to make that much of a
> > difference.
> > 
> > I concluded, similar to Andi, that stop_machine() is too big of a hammer.
> > 
> > I wonder if something could be built out of preempt_disable() and sync SMP
> > calls. hmm :(
> 
> Scrap that, shouldn't work I think ...
> 

Wait a sec, what about call_rcu_tasks? Use that and re-check the bit is
still set?

-- 
MST