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

[Breno Leitao <leitao@debian.org>]

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.

Thanks for the review,
--breno