On Wed, May 13, 2026 at 08:39:32AM -0700, Breno Leitao wrote:
>The first entry of error_states[],
>
> { reserved, reserved, MF_MSG_KERNEL, me_kernel },
>
>is unreachable. identify_page_state() has two callers, and neither
>one can dispatch a PG_reserved page to me_kernel():
>
> * memory_failure() reaches identify_page_state() only after
> get_hwpoison_page() returned 1. get_any_page() reaches that
> return only via __get_hwpoison_page(), which gates the refcount
> on HWPoisonHandlable(). HWPoisonHandlable() rejects PG_reserved
> pages, so they fail with -EBUSY/-EIO long before
> identify_page_state() runs.
HWPoisonHandlable() does not test PG_reserved directly; it only lets
LRU or free buddy pages through:
return PageLRU(page) || is_free_buddy_page(page);
So this really relies on PG_reserved not being combined with either of
those states. I would not expect that to happen, though.
>
> * try_memory_failure_hugetlb() reaches identify_page_state() on
> the MF_HUGETLB_IN_USED branch, but the page is necessarily a
> hugetlb folio there. The first table entry that matches a
> hugetlb folio is { head, head, MF_MSG_HUGE, me_huge_page }, so
> they dispatch to me_huge_page() before the (now-removed)
> reserved entry would have matched, regardless of whether
> PG_reserved happens to be set on the head page.
As David pointed out, hugetlb setup clears PG_reserved before setting
PG_head. See hugetlb_folio_init_vmemmap():
__folio_clear_reserved(folio);
__folio_set_head(folio);
>
>me_kernel() never executes and the entry exists only to be matched
>against by code that cannot see it.
identify_page_state() is reached only when get_hwpoison_page()
returns 1, but a PG_reserved page would not get that far, IIUC :)
>
>Drop the entry, the me_kernel() helper, and the now-unused
>"reserved" macro. Leave the MF_MSG_KERNEL enum value in place: it
>remains part of the tracepoint and pr_err() string tables, and
>follow-on work to classify unrecoverable kernel pages can reuse it
>without churning the user-visible enum.
>
>No functional change.
>
>Suggested-by: David Hildenbrand <[email protected]>
>Signed-off-by: Breno Leitao <[email protected]>
>---
With David's comments addressed, feel free to add:
Reviewed-by: Lance Yang <[email protected]>
