Re: [PATCH v3 2/2] mm/memory-failure: teach kill_accessing_process to accept hugetlb tail page pfn

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 12/23/25 02:21, Jane Chu wrote:
> When a hugetlb folio is being poisoned again, try_memory_failure_hugetlb()
> passed head pfn to kill_accessing_process(), that is not right.
> The precise pfn of the poisoned page should be used in order to
> determine the precise vaddr as the SIGBUS payload.
> 
> This issue has already been taken care of in the normal path, that is,
> hwpoison_user_mappings(), see [1][2].  Further more, for [3] to work
> correctly in the hugetlb repoisoning case, it's essential to inform
> VM the precise poisoned page, not the head page.
> 
> [1] https://lkml.kernel.org/r/20231218135837.3310403-1-willy@infradead.org
> [2] https://lkml.kernel.org/r/20250224211445.2663312-1-jane.chu@oracle.com
> [3] https://lore.kernel.org/lkml/20251116013223.1557158-1-jiaqiyan@google.com/
> 
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Jane Chu <jane.chu@oracle.com>
> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> ---
> v2 -> v3:
>    incorporated suggestions from Miaohe and Matthew.
> v1 -> v2:
>    pickup R-B, add stable to cc list.

Please don't send new versions when the discussions on your old 
submissions are still going on. Makes the whole discussion hard to follow.

You asked in the old version:

"
What happens if non-head PFN of hugetlb is indicated in a SIGBUG to
QEMU?  Because, the regular path, the path via hwpoison_user_mappings()
already behave this way.

I'm not familiar with QEMU. AFAIK, the need for this patch came from our
VM/QEMU team.
"

I just took a look and I think it's ok. I remembered a discussion around 
[1] where we concluded that the kernel would always give us the first 
PFN, but essentially the whole hugetlb folio will vanish.

But in QEMU we work completely on the given vaddr, and are able to 
identify that it's a hugetlb folio through our information on memory 
mappings.

QEMU stores a list of positioned vaddrs, to remap them (e.g., 
fallocate(PUNCH_HOLE)) when restarting the VM. If we get various vaddrs 
for the same hugetlb folio we will simply try to remap a hugetlb folio 
several times, which is not a real problem. I think we discussed that 
that could get optimized as part of [1] (or follow-up versions) if ever 
required.

[1] 
https://lore.kernel.org/qemu-devel/20240910090747.2741475-1-william.roche@oracle.com/


-- 
Cheers

David