From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 797E627B338 for ; Sat, 11 Oct 2025 18:19:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760206740; cv=none; b=ErruOphWOkywStpu2wYAgvkNIjy6mtWqoxwQDVyHxmGHdF2r00DUEURs9ynJqxQ9EnsfK57jmwOH6BXjh0prtXqmtdWqbHBa92uixBBXc+z9sUXfPA4uv+V9+DAqGebQZhzXHclfU1NYu8au7P5/w5DSAktI7lwX6i0tCMO+wWc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760206740; c=relaxed/simple; bh=MPdjkQnoZTr/N788IvZN1eosYtsrWQ4gFL5Wool50+I=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=RoxWi6NVgqVIotbasbEraPhqq2Ld+Vj+eymAUC6mJO/+KfGOIQHsTaeyymTlBejj8bQrbAgLaf1evtOSQN9px58hhs1MbrrgE53JZX1jBDArJ6O9cC4tRDjkNyYdtwgnJi50HXdjl9Ao8qyed9kvlt8R/B4k27bGzULtfZkNpZY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=DmGGkDAW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="DmGGkDAW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53A3CC4CEF4; Sat, 11 Oct 2025 18:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1760206739; bh=MPdjkQnoZTr/N788IvZN1eosYtsrWQ4gFL5Wool50+I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DmGGkDAWyxw6viSxHi+wXwHoIs/wtxfbFrp8PXdOaFKdhHAkvu640pgNrP1RuzKPX rd64pTypgtTSHWy/PY7AV4KGqcwGqw74ou1UGkZekuM1MP/fL7rCqfc1RnbghdfCKl ZyScDxgh35p+cvheSFmMIKwnMBMwtAqhDjC8zWP0= Date: Sat, 11 Oct 2025 11:18:58 -0700 From: Andrew Morton To: Qiuxu Zhuo Cc: david@redhat.com, lorenzo.stoakes@oracle.com, linmiaohe@huawei.com, tony.luck@intel.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, nao.horiguchi@gmail.com, farrah.chen@intel.com, jiaqiyan@google.com, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/1] mm: prevent poison consumption when splitting THP Message-Id: <20251011111858.952f08213da2a9018cfbe2b3@linux-foundation.org> In-Reply-To: <20251011075520.320862-1-qiuxu.zhuo@intel.com> References: <20250928032842.1399147-1-qiuxu.zhuo@intel.com> <20251011075520.320862-1-qiuxu.zhuo@intel.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 11 Oct 2025 15:55:19 +0800 Qiuxu Zhuo 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: {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 > Suggested-by: David Hildenbrand > Tested-by: Farrah Chen > Tested-by: Qiuxu Zhuo > Signed-off-by: Qiuxu Zhuo Yes please, a Fixes: would be good. > + if (folio_contain_hwpoisoned_page(folio)) Offtopic, that should have been "folio_contains_hwpoisoned_page".