Re: [PATCH v2 1/3] mm/memory-failure: report MF_MSG_KERNEL for reserved pages

[Breno Leitao]

On Tue, Apr 07, 2026 at 10:56:39AM +0800, Miaohe Lin wrote:
> On 2026/3/31 19:00, Breno Leitao wrote:
> > When get_hwpoison_page() returns a negative value, distinguish
> > reserved pages from other failure cases by reporting MF_MSG_KERNEL
> > instead of MF_MSG_GET_HWPOISON. Reserved pages belong to the kernel
> > and should be classified accordingly for proper handling by the
> > panic_on_unrecoverable_memory_failure mechanism.
> > 
> > Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
> > ---
> >  mm/memory-failure.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index ee42d4361309..6ff80e01b91a 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -2432,7 +2432,11 @@ int memory_failure(unsigned long pfn, int flags)
> >  		}
> >  		goto unlock_mutex;
> >  	} else if (res < 0) {
> > -		res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
> > +		if (PageReserved(p))
> > +			res = action_result(pfn, MF_MSG_KERNEL, MF_IGNORED);
> 
> Is it safe or common to check page flags without holding extra refcnt?


Yes, this is safe. At this point the page has HWPoison set, preventing
reallocation.

PageReserved is an atomic flag test on struct page memory that's always
valid for online PFNs.

Reserved pages are inherently stable (kernel text, firmware, etc.) and
don't change status dynamically.

This follows the same pattern as the existing is_free_buddy_page(p)
check a few lines above, which also reads page state without an extra
refcount.

The result is only used for a detailed classification, so even a theoretical
race would not be a bad issue.