Re: [PATCH splitout] mm: memory-failure: serialize TestSetPageHWPoison with zone->lock

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

On 6/16/26 23:35, Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2026 at 02:18:57PM +0200, David Hildenbrand (Arm) wrote:
>> On 6/16/26 13:40, Miaohe Lin wrote:
>>>
>>> I scanned the code and found rcu_read_unlock_special might be called in some cases.
>>> Some expensive ops, e.g. irq_work_queue_on, might be called in some corner cases.
>>> So the overhead of rcu read lock might be fluctuating.
>>
>> Right. Usually rcu_read_lock+unlock is supposed to be very lightweight, but that
>> might not be completely the case with that PREEMPT_RCU thingy ...
>>
>>>
>>>
>>> Sure. We can do that if needed.
>>>
>>>
>>> Right. hypervisor could make the issue easier to trigger...
>>>
>>>
>>> I think your proposal, although there are still some issues to be resolved, is
>>> nevertheless a good solution. We could also wait and see if anyone comes up with
>>> a better one.
>>
>> I wouldn't call it "good" ... it's the only thing I was easily able to come up
>> with :)
>>
>> The only alternative would be moving the hwpoison bit out of page->flags,
>> storing it in a sparse bitmap or sth. like that. It would be a bigger rework and
>> I am sure there are issues with that as well.
>>
>> -- 
>> Cheers,
>>
>> David
> 
> 
> I had a vague feeling using static keys should be possible somehow,
> but could not come up with anything robust.

I skimmed over it, but concluded that it's worse than what I envisioned. (e.g.,
two rcu read lock+unlock over consecutive updates).

It's also doesn't address the mf_mutex implications and the x86 thingies I
mentioned.

The rcu_is_watching() optimization is interesting, wonder though if that is
really relevant in practice.

I'll either take care of that myself or find someone that can work on this with
attention to all details.

-- 
Cheers,

David