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@or...