linux-kernel - Re: [PATCH v2 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] [day] [month] [year] [list]

Message-Id: <20251011111858.952f08213da2a9018cfbe2b3@linux-foundation.org>
Date: Sat, 11 Oct 2025 11:18:58 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
Cc: david@...hat.com, lorenzo.stoakes@...cle.com, linmiaohe@...wei.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, jiaqiyan@...gle.com, lance.yang@...ux.dev,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] mm: prevent poison consumption when splitting
 THP

On Sat, 11 Oct 2025 15:55:19 +0800 Qiuxu Zhuo <qiuxu.zhuo@...el.com> wrote:

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

Well that sounds dumb.  To me this suggests a lack of selftesting code.
Perhaps someone could prepare a test for this case.

> occurring before
> the initial memory_failure() completes, ultimately leading to a kernel
> panic. See the kernel panic call trace on the two #MCs.
> 
> ...
>
> Reported-by: Farrah Chen <farrah.chen@...el.com>
> Suggested-by: David Hildenbrand <david@...hat.com>
> Tested-by: Farrah Chen <farrah.chen@...el.com>
> Tested-by: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
> Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@...el.com>

Yes please, a Fixes: would be good.

> +	if (folio_contain_hwpoisoned_page(folio))

Offtopic, that should have been "folio_contains_hwpoisoned_page".