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

[Breno Leitao <leitao@debian.org>]

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.

Reproducing the race from userspace is hard because the window is
microseconds wide inside the allocator.

If you think this test doesn't bring any value, i am happy to just drop it.