Re: [PATCH v7 1/6] mm/memory-failure: drop dead error_states[] entry for reserved pages

[Lance Yang]

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 <david@xxxxxxxxxx>
>Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
>---

With David's comments addressed, feel free to add:
Reviewed-by: Lance Yang <lance.yang@xxxxxxxxx>