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

[jane.chu@oracle.com]

On 12/23/2025 1:13 AM, David Hildenbrand (Red Hat) wrote:
> 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.

Got it, thanks.

> 
> 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/
> 

Thanks a lot!

-jane
>