Re: [PATCH v4 2/3] mm/memory-failure: add panic option for unrecoverable pages

[Miaohe Lin]

On 2026/4/27 22:49, Breno Leitao wrote:
> On Mon, Apr 27, 2026 at 10:44:55AM +0800, Miaohe Lin wrote:
>> On 2026/4/24 20:01, Breno Leitao wrote:
>>> On Thu, Apr 23, 2026 at 10:38:19AM +0800, Miaohe Lin wrote:
>>>>> are you suggesting I drop MF_MSG_KERNEL_HIGH_ORDER from here, or, document this
>>>>> will not hit userspace pages?
>>>>
>>>> No, maybe we should rule out or document above rare case if I'm not miss something.
>>>
>>> Good catch. A buddy page being concurrently allocated to userspace can
>>> briefly satisfy get_hwpoison_page() == 0 && !is_free_buddy_page(), and
>>> that page is recoverable via the standard SIGBUS path — panicking on
>>> it would be wrong.
>>>
>>> The page allocator can't filter it out either.
>>>
>>> check_new_pages() is gated by is_check_pages_enabled() and is a no-op
>>> when CONFIG_DEBUG_VM=n.
>>>
>>> For v6 I'll try to rule out the race inside panic_on_unrecoverable_mf() so
>>> action_result() stays unchanged:
>>>
>>> 	case MF_MSG_KERNEL_HIGH_ORDER:
>>> 	p = pfn_to_online_page(pfn);
>>> 	if (!p)
>>> 		return true;
>>> 	cpu_relax();
>>> 	return page_count(p) == 0 &&
>>> 		!PageLRU(p) &&
>>> 		!page_mapped(p) &&
>>> 		!page_folio(p)->mapping &&
>>> 		!is_free_buddy_page(p);
>>>
>>>
>>> A buddy page being allocated must transit rmqueue() → prep_new_page() →
>>> post_alloc_hook() before the caller can use it. Each step either bumps
>>> _refcount or sets state we can observe (PageLRU, ->mapping). cpu_relax()
>>> lets that remote-CPU progress become visible before we resample.
>>>
>>> A genuine non-buddy high-order kernel tail page stays unowned across the
>>> recheck, so the panic still fires on the case this series targets.
>>>
>>> The window is much narrowed now, not eliminated — I'll say so in the changelog.
>>>
>>> I also added a selftest that enables the sysctl, injects MADV_HWPOISON
>>> on a userspace anon page in a forked child, and asserts SIGBUS (not a
>>> panic). I've been running this in a loop for hours, and I haven't seen any
>>> false positive.
>>
>> The userspace anon pages are already allocated. Those pages are in a stable state.
>> So your selftest cannot test above window. Or am I miss something?
> 
> You're right, the test doesn't directly hit the race window. By the time
> madvise(MADV_HWPOISON) runs the page is fully owned by the process and goes
> through the steady-state SIGBUS path; the buddy→user transition that the
> recheck guards is already over.
> 
> What the test actually proves is the negative: the recheck didn't break the
> common, non-racing path — i.e. a normal recoverable userspace page still
> returns SIGBUS instead of panicking. It's a smoke test against gross
> regressions of the recheck logic, not a reproducer of the original race.

Got it. It would be really helpful to have a selftest guard against sysctl_panic_on_unrecoverable_mf.

Thanks.
.