linux-kernel - Re: [PATCH 1/1] mm: prevent poison consumption when splitting THP

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: <5f117b73-8d7b-b233-a0a8-2a29ea6312a8@huawei.com>
Date: Mon, 29 Sep 2025 20:29:42 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Jiaqi Yan <jiaqiyan@...gle.com>, Qiuxu Zhuo <qiuxu.zhuo@...el.com>
CC: <akpm@...ux-foundation.org>, <david@...hat.com>,
	<lorenzo.stoakes@...cle.com>, <tony.luck@...el.com>, <ziy@...dia.com>,
	<baolin.wang@...ux.alibaba.com>, <Liam.Howlett@...cle.com>,
	<npache@...hat.com>, <ryan.roberts@....com>, <dev.jain@....com>,
	<baohua@...nel.org>, <nao.horiguchi@...il.com>, <farrah.chen@...el.com>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, Andrew Zaborowski
	<andrew.zaborowski@...el.com>
Subject: Re: [PATCH 1/1] mm: prevent poison consumption when splitting THP

On 2025/9/29 5:55, Jiaqi Yan wrote:
> On Sat, Sep 27, 2025 at 8:30 PM Qiuxu Zhuo <qiuxu.zhuo@...el.com> wrote:
>>
>> From: Andrew Zaborowski <andrew.zaborowski@...el.com>
>>
>> When performing memory error injection on a THP (Transparent Huge Page)
>> mapped to userspace on an x86 server, the kernel panics with the following
>> trace. The expected behavior is to terminate the affected process instead
>> of panicking the kernel, as the x86 Machine Check code can recover from an
>> in-userspace #MC.
>>
>>   mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134
>>   mce: [Hardware Error]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0}
>>   mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db
>>   mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320
>>   mce: [Hardware Error]: Run the above through 'mcelog --ascii'
>>   mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
>>   Kernel panic - not syncing: Fatal local machine check
>>
>> The root cause of this panic is that handling a memory failure triggered by
>> an in-userspace #MC necessitates splitting the THP. The splitting process
>> employs a mechanism, implemented in try_to_map_unused_to_zeropage(), which
>> reads the sub-pages of the THP to identify zero-filled pages. However,
>> reading the sub-pages results in a second in-kernel #MC, occurring before
>> the initial memory_failure() completes, ultimately leading to a kernel
>> panic. See the kernel panic call trace on the two #MCs.
>>
>>   First Machine Check occurs // [1]
>>     memory_failure()         // [2]
>>       try_to_split_thp_page()
>>         split_huge_page()
>>           split_huge_page_to_list_to_order()
>>             __folio_split()  // [3]
>>               remap_page()
>>                 remove_migration_ptes()
>>                   remove_migration_pte()
>>                     try_to_map_unused_to_zeropage()
> 
> Just an observation: Unfortunately THP only has PageHasHWPoisoned and
> don't know the exact HWPoisoned page. Otherwise, we may still use
> zeropage for these not HWPoisoned.

IIUC, the raw error page will have HWPoisoned flag set while the THP has
PageHasHWPoisoned set. So I think we could use zeropage for healthy sub-pages.

Thanks.
.