linux-kernel - Re: [PATCH v3 2/2] mm/memory-failure: teach kill_accessing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3ea133e-7160-4149-ad69-d11c6bfc213e@oracle.com>
Date: Tue, 23 Dec 2025 10:17:30 -0800
From: jane.chu@...cle.com
To: "David Hildenbrand (Red Hat)" <david@...nel.org>,
        linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, stable@...r.kernel.org, muchun.song@...ux.dev,
        osalvador@...e.de, linmiaohe@...wei.com, jiaqiyan@...gle.com,
        william.roche@...cle.com, rientjes@...gle.com,
        akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com,
        Liam.Howlett@...cle.com, rppt@...nel.org, surenb@...gle.com,
        mhocko@...e.com, willy@...radead.org
Subject: Re: [PATCH v3 2/2] mm/memory-failure: teach kill_accessing_process to
 accept hugetlb tail page pfn

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@...radead.org
>> [2] https://lkml.kernel.org/r/20250224211445.2663312-1- 
>> jane.chu@...cle.com
>> [3] https://lore.kernel.org/lkml/20251116013223.1557158-1- 
>> jiaqiyan@...gle.com/
>>
>> Cc: <stable@...r.kernel.org>
>> Signed-off-by: Jane Chu <jane.chu@...cle.com>
>> Reviewed-by: Liam R. Howlett <Liam.Howlett@...cle.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@...cle.com/
> 

Thanks a lot!

-jane
>