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

[Lance Yang <lance.yang@linux.dev>]

On Mon, Apr 27, 2026 at 05:49:28PM +0200, David Hildenbrand (Arm) wrote:
>> +	switch (type) {
>> +	case MF_MSG_KERNEL:
>> +	case MF_MSG_UNKNOWN:
>> +		return true;
>> +	case MF_MSG_KERNEL_HIGH_ORDER:
>> +		/*
>> +		 * Rule out a concurrent buddy allocation: give the
>> +		 * allocator a moment to finish prep_new_page() and
>> +		 * re-check. A genuine high-order kernel tail page stays
>> +		 * unowned; an in-flight allocation will have bumped the
>> +		 * refcount, attached a mapping, or placed the page on
>> +		 * an LRU by now.
>> +		 */
>> +		p = pfn_to_online_page(pfn);
>> +		if (!p)
>> +			return true;
>> +		/*
>> +		 * Yield so a concurrent allocator on another CPU can
>> +		 * finish prep_new_page() and have its writes become
>> +		 * visible before we resample the page state.
>> +		 */
>> +		cpu_relax();
>> +		return page_count(p) == 0 &&
>> +		       !PageLRU(p) &&
>> +		       !page_mapped(p) &&
>> +		       !page_folio(p)->mapping &&
>> +		       !is_free_buddy_page(p);
>
>I don't get what you are doing here. The right way to check for a tail page is
>not by checking the refcount.
>
>Further, you are not holding a folio reference? If so, calling
>page_mapped/folio_mapped is shaky. On concurrent folio split you can trigger a
>VM_WARN_ON_FOLIO().
>
>
>Maybe folio_snapshot() is what you are looking for, if you are in fact not
>holding a reference?

Right! Maybe we should not try to make this decision in
panic_on_unrecoverable_mf().

By the time we get here, we only know the final MF_MSG_* type. The
real reason why get_hwpoison_page() failed is already lost.

Wonder if it would be better to split that earlier, around
__get_unpoison_page()/get_any_page(). That code still knows why
grabbing the page failed, either an unsupported kernel page or
just a temporary race we cannot really trust :)

Then the later panic logic can be simple: panic for the stable
unsupported kernel page case, and not for the temporary race case.

That would also avoid trying to guess MF_MSG_KERNEL_HIGH_ORDER here:)

Cheers,
Lance