From nobody Sat Feb 7 22:47:42 2026 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (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 D6E451487E1 for ; Tue, 21 Jan 2025 04:19:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737433168; cv=none; b=hMbIndI7i7b8y2H2VvLn1NBNBz1faaFUuKTNr6VRMLxncPwbvetam8lCoXkFe/Xu/6/hRWJgGfNtjOQabvpyWhjoeaabHQPP5BeGzE+lPR3ENNXMx2bwK0e0XmfQK5z5HNHvQZqz4Tp4fio//YM1Hl2RGYeAYKISag+saQZaUW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737433168; c=relaxed/simple; bh=Jnki1d8k03Pa/J751wxPM8tJVzuGGpQmzKkJT2e0464=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=PXra0CVoZGt30BjD9BkQAlJa1rk83pbV9z9H9czFxMlCIfYMttGOrz2W4Xo2RET7JTeiDqxNqCDZRe5RuMiF3xRlVQOs0Kc/cvbWc+YdIvshSr9ZBNfVBeRxae0whSQxMquLuge3hByKgrnB0xXyo2uWufIk83OZFo9CB/r8Dlc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=oDy7lGfi; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="oDy7lGfi" Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50KGMvNH024767; Tue, 21 Jan 2025 04:19:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h= content-transfer-encoding:date:from:message-id:mime-version :subject:to; s=corp-2023-11-20; bh=9HM1nA931kHrw3m9SclaY3HXr64my M0TA+bCFRYgF6A=; b=oDy7lGfiAYrNO3zs6nsiGG8c+4YUokIH9dg4V224GP4zh d2JerNGJ5P7dOsQX8FwQK6D2UspuWb1wuhBGKTp51YJ72e5i60NXh0ChNnnfsU0P k0ZuvZXIBOuHwX3X527bTgMXJaL3aRSow1noBTNSV4dDbMtfOgGYnUSRlcHAaWEW QI14nf8owh1d6co21wgqAZ5JolhTYPvssAfsLqS4ik9kfJGFUndqoKFRpiwYFl1Z 9K106IwCBC4zdSUeN99pPaNpY+r4YEChgV2IBPI8Wn5+TykDSmfkmuox34q0vv41 jgNM2VuVrHPSi8DYhVLQ1irPnzbJK+tl9zvM5ZJhw== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4485q54p9n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jan 2025 04:19:05 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 50L3VOaB029518; Tue, 21 Jan 2025 04:19:04 GMT Received: from brm-x62-16.us.oracle.com (brm-x62-16.us.oracle.com [10.80.150.37]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id 4491fh8x8p-1; Tue, 21 Jan 2025 04:19:04 +0000 From: Jane Chu To: akpm@linux-foundation.org, willy@infradead.org, linmiaohe@huawei.com, kirill.shutemov@linux.intel.com, hughd@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm: make page_mapped_in_vma() hugetlb walk aware Date: Mon, 20 Jan 2025 21:18:49 -0700 Message-Id: <20250121041849.3393237-1-jane.chu@oracle.com> X-Mailer: git-send-email 2.39.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-21_02,2025-01-20_03,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 adultscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501210033 X-Proofpoint-GUID: 4L0YNqVH6rUM6CM6SAt0YM0Xn3C7wwat X-Proofpoint-ORIG-GUID: 4L0YNqVH6rUM6CM6SAt0YM0Xn3C7wwat Content-Type: text/plain; charset="utf-8" When a process consumes a UE in a page, the memory failure handler attempts to collect information for a potential SIGBUS. If the page is an anonymous page, page_mapped_in_vma(page, vma) is invoked in order to 1. retrieve the vaddr from the process' address space, 2. verify that the vaddr is indeed mapped to the poisoned page, where 'page' is the precise small page with UE. It's been observed that when injecting poison to a non-head subpage of an anonymous hugetlb page, no SIGBUS show up; while injecting to the head page produces a SIGBUS. The casue is that, though hugetlb_walk() returns a valid pmd entry (on x86), but check_pte() detects mismatch between the head page per the pmd and the input subpage. Thus the vaddr is considered not mapped to the subpage and the process is not collected for SIGBUS purpose. This is the calling stack collect_procs_anon page_mapped_in_vma page_vma_mapped_walk hugetlb_walk huge_pte_lock check_pte It seems that the most obvious place to fix the issue is by making page_mapped_in_vma() hugetlb walk aware. The precise subpage in the input is useful in providing PAGE_SIZE granularity vaddr. Signed-off-by: Jane Chu --- mm/page_vma_mapped.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c index 81839a9e74f1..bc036060cc68 100644 --- a/mm/page_vma_mapped.c +++ b/mm/page_vma_mapped.c @@ -342,15 +342,26 @@ unsigned long page_mapped_in_vma(const struct page *p= age, { const struct folio *folio =3D page_folio(page); struct page_vma_mapped_walk pvmw =3D { - .pfn =3D page_to_pfn(page), .nr_pages =3D 1, .vma =3D vma, .flags =3D PVMW_SYNC, }; =20 + /* fine granularity address is always preferred */ pvmw.address =3D vma_address(vma, page_pgoff(folio, page), 1); if (pvmw.address =3D=3D -EFAULT) goto out; + + /* + * Hugetlb doesn't support partial page-mapping, hugetlb_walk() + * simply assumes hugetlb pte, hence feed the headpage pfn for + * the walk and pte check. + */ + if (folio_test_hugetlb(folio)) + pvmw.pfn =3D folio_pfn(folio); + else + pvmw.pfn =3D page_to_pfn(page); + if (!page_vma_mapped_walk(&pvmw)) return -EFAULT; page_vma_mapped_walk_done(&pvmw); --=20 2.39.3