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

[Breno Leitao <leitao@debian.org>]

On Sun, May 10, 2026 at 10:42:20PM +0800, Lance Yang wrote:
> 
> On Wed, May 06, 2026 at 09:18:12AM -0700, Breno Leitao wrote:
> >On Tue, Apr 28, 2026 at 11:07:21AM +0800, Lance Yang wrote:
> >> 
> >> 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:)
> >
> >This is a very good feedback, and definitely what I wanted to do, but,
> >failed. Once we have the reason, we don't need this dance to guess the
> >reason.
> >
> >I've hacked a patch based on this approach. How does it sound?
> 
> Yes. This direction makes sense to me, not an expert though :D
> 
> I played with something similar (untested) on top of patch #01:

Thanks!

I'll prepare a new series addressing all the feedback from both
reviewers and AI analysis. I will resend soon and we can catch up
on the next revision,

Thanks for the review,
--breno