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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/1/26 17:54, Michael S. Tsirkin wrote:
> On Wed, Jul 01, 2026 at 10:36:31AM +0200, David Hildenbrand (Arm) wrote:
>> On 7/1/26 10:33, Michael S. Tsirkin wrote:
>>>
>>> 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.

What I thought.

> Still hacking on it, but the difficulty
> with memory-failure is that fundamentally, it's not 100% robust.

It's all a bit slapped on top of everything, yes.

What I was wondering is, assuming the call_task_rcu() and it takes forever,
there might be quite a while where a hwpoisoned page that lost its bit is not
marked as hwpoisoned.

So you'd actually want the one doing the test_and_set_bit() caller to wait until
the bit is stable.

But that should be rather hairy as well. :(

> 
> 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?

I guess so. I assume on relevant hw you wouldn't expect a storm. But who knows :)

> 
> 
> 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.

When we poison, we try to take the free page off the buddy. At least that's what
I remember.

So I think we would just then go ahead and split the free higher-order buddy
page to remove the single page.

-- 
Cheers,

David