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

[Breno Leitao <leitao@debian.org>]

On Wed, May 13, 2026 at 10:10:27PM +0200, David Hildenbrand (Arm) wrote:
> On 5/13/26 17:39, Breno Leitao wrote:
> >   * 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.
> 
> You should clarify why they are rejected. There is no explicit check for
> PG_reserved in there!

True, I meant that PG_reserved pages do not fit any of the criterias of
HWPoisonHandlable().

I will rewrite it more explictly:

	__get_hwpoison_page() only takes a refcount when the page is
	HWPoisonHandlable()'d, and HWPoisonHandlable() is an allowlist for LRU /
	free-buddy / (soft-offline) movable_ops pages.

is it any better?

> >   * 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.
> 
> See hugetlb_folio_init_vmemmap(): we always clear PG_reserved for hugetlb folios
> allocated from memblock.

Thanks. I clearly see a call to __folio_clear_reserved(folio), so, huge pagetlb folios
are never reserved.

A better summary would be:

	try_memory_failure_hugetlb() reaches identify_page_state() only via the
	MF_HUGETLB_IN_USED branch, as hugetlb folios don't carry PG_reserved at
	that point (hugetlb_folio_init_vmemmap() clears it during init).

> Yes, I think this should work.
> 
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>

Thanks for the review,
--breno