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:36:31AM +0200, David Hildenbrand (Arm) wrote:
> On 7/1/26 10:33, Michael S. Tsirkin wrote:
> > On Wed, Jul 01, 2026 at 10:26:26AM +0200, David Hildenbrand (Arm) wrote:
> >> On 7/1/26 10:18, Michael S. Tsirkin wrote:
> >>>
> >>> 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?
> 
> As RFC please :) [and if it's AI generated, obviously properly reviewed and
> reworked by you]
> -- 
> Cheers,
> 
> David

Not "generated" surely. But assisted, yes. Still hacking on it, but the difficulty
with memory-failure is that fundamentally, it's not 100% robust.

For example, we have a fifo fed by hardware and consumed by a workqueue:

        struct memory_failure_cpu *mf_cpu;
        unsigned long proc_flags;
        bool buffer_overflow;
        struct memory_failure_entry entry = {
                .pfn =          pfn,
                .flags =        flags,
        };

        mf_cpu = &get_cpu_var(memory_failure_cpu);
        raw_spin_lock_irqsave(&mf_cpu->lock, proc_flags);
        buffer_overflow = !kfifo_put(&mf_cpu->fifo, entry);
        if (!buffer_overflow)
                schedule_work_on(smp_processor_id(), &mf_cpu->work);
        raw_spin_unlock_irqrestore(&mf_cpu->lock, proc_flags);
        put_cpu_var(memory_failure_cpu);
        if (buffer_overflow)
                pr_err("buffer overflow when queuing memory failure at %#lx\n",
                       pfn);


if there are lots of these and the scheduler is slow and it overflows,
it's sayonara you have lost the flag, right?


Oh and by the way, I just noticed that when buddy merges pages it does
not check the poison bit. So it looks like there's a simple way to lose
the poison bit - have it merge with a non poisoned page.

I guess maybe we should fix this last one.

-- 
MST