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 002E4306483 for ; Wed, 18 Feb 2026 13:06:13 +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=1771419974; cv=none; b=kz/62f8NI9a9sw62Z2Gxqk96OKF/0x5tBjdCgqft3EG1aEuj9ldfUf/p41SRQ6X8eLM+ab8D0khVRK48gNEglsgHZk+mOXggaOEGMCuue5fZFJUufqSiLIY9L7rBA1cFy9GKrKPO4cJe3EBbZXmvbBUVMH42yLAMArg8VkJd9aw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771419974; c=relaxed/simple; bh=sELUiTI6/PHGGIB3tYh4aGzx7GNn+Emzhk47tBilGpQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HC02rbq8CjIGphbbZ8kLw3VAs3fCITctbcePA8B1DTe3dyPV6zb4AqAzg6r6ydmKtUqn2rq2wy/m87rOJMz+Z3GfbqkCW7buxUGZhH2GEsCpF34uQ0rN47v3Ydt5GcvszWwh0FciD+l27nPOOjT4ss1nFRk1cGUxojdPt0BjLBU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=byesko0H; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="byesko0H" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1C9EC19425; Wed, 18 Feb 2026 13:06:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771419973; bh=sELUiTI6/PHGGIB3tYh4aGzx7GNn+Emzhk47tBilGpQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=byesko0HKQd1y3l+/FbQiLgz16Q0vDuOcHw9VdbMa4KgrLlk5Ltxss1hkkqU+wKLa mGllECQcrMr4LtwO3xbOnYJUG9WyyrEbus1R6S/rY6CMKS7L3W/AHE+NAKCIWBQ268 eYbngke9r24N1EK1DXvsoBwlWju1zDhvguUoblxtmp1fFoEZ8dw25+SfXsTQ9voRJo U/COOkiiHDX4zGX+l9n8tQN0fFokrgTlGdl6A2ewF4sIdUi8VjGK3cts2Q8Yz6pHrt jervQxMkXtX67HAXj0D7yMv7FsJgfN+aFxg2qgQvANmK/nfiqLjmqroJ4dz3fjEpgC OSBq/lVjRvOqQ== From: "David Hildenbrand (Arm)" To: stable@vger.kernel.org Cc: linux-mm@kvack.org, "David Hildenbrand (Arm)" , Jane Chu , Harry Yoo , Oscar Salvador , Jann Horn , Liu Shixin , Muchun Song , Andrew Morton , Rik van Riel , Laurence Oberman , Lance Yang , Miaohe Lin , James Houghton , David Hildenbrand Subject: [PATCH 5.10.y 3/7] mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count Date: Wed, 18 Feb 2026 14:05:48 +0100 Message-ID: <20260218130552.55727-4-david@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260218130552.55727-1-david@kernel.org> References: <2026012610-absolve-ducktail-3c64@gregkh> <20260218130552.55727-1-david@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Jane Chu commit 59d9094df3d79 ("mm: hugetlb: independent PMD page table shared count") introduced ->pt_share_count dedicated to hugetlb PMD share count tracking, but omitted fixing copy_hugetlb_page_range(), leaving the function relying on page_count() for tracking that no longer works. When lazy page table copy for hugetlb is disabled, that is, revert commit bcd51a3c679d ("hugetlb: lazy page table copies in fork()") fork()'ing with hugetlb PMD sharing quickly lockup - [ 239.446559] watchdog: BUG: soft lockup - CPU#75 stuck for 27s! [ 239.446611] RIP: 0010:native_queued_spin_lock_slowpath+0x7e/0x2e0 [ 239.446631] Call Trace: [ 239.446633] [ 239.446636] _raw_spin_lock+0x3f/0x60 [ 239.446639] copy_hugetlb_page_range+0x258/0xb50 [ 239.446645] copy_page_range+0x22b/0x2c0 [ 239.446651] dup_mmap+0x3e2/0x770 [ 239.446654] dup_mm.constprop.0+0x5e/0x230 [ 239.446657] copy_process+0xd17/0x1760 [ 239.446660] kernel_clone+0xc0/0x3e0 [ 239.446661] __do_sys_clone+0x65/0xa0 [ 239.446664] do_syscall_64+0x82/0x930 [ 239.446668] ? count_memcg_events+0xd2/0x190 [ 239.446671] ? syscall_trace_enter+0x14e/0x1f0 [ 239.446676] ? syscall_exit_work+0x118/0x150 [ 239.446677] ? arch_exit_to_user_mode_prepare.constprop.0+0x9/0xb0 [ 239.446681] ? clear_bhb_loop+0x30/0x80 [ 239.446684] ? clear_bhb_loop+0x30/0x80 [ 239.446686] entry_SYSCALL_64_after_hwframe+0x76/0x7e There are two options to resolve the potential latent issue: 1. warn against PMD sharing in copy_hugetlb_page_range(), 2. fix it. This patch opts for the second option. While at it, simplify the comment, the details are not actually relevant anymore. Link: https://lkml.kernel.org/r/20250916004520.1604530-1-jane.chu@oracle.com Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count") Signed-off-by: Jane Chu Reviewed-by: Harry Yoo Acked-by: Oscar Salvador Acked-by: David Hildenbrand Cc: Jann Horn Cc: Liu Shixin Cc: Muchun Song Signed-off-by: Andrew Morton (cherry picked from commit 14967a9c7d247841b0312c48dcf8cd29e55a4cc8) [ David: We don't have ptdesc and the wrappers, so work directly on the page->pt_share_count. CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING is still called CONFIG_ARCH_WANT_HUGE_PMD_SHARE. ] Signed-off-by: David Hildenbrand (Arm) --- mm/hugetlb.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index a2cab8f2190f..8fa34032bc17 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3865,16 +3865,11 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, break; } - /* - * If the pagetables are shared don't copy or take references. - * - * dst_pte == src_pte is the common case of src/dest sharing. - * However, src could have 'unshared' and dst shares with - * another vma. So page_count of ptep page is checked instead - * to reliably determine whether pte is shared. - */ - if (page_count(virt_to_page(dst_pte)) > 1) +#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE + /* If the pagetables are shared, there is nothing to do */ + if (atomic_read(&virt_to_page(dst_pte)->pt_share_count)) continue; +#endif dst_ptl = huge_pte_lock(h, dst, dst_pte); src_ptl = huge_pte_lockptr(h, src, src_pte); -- 2.43.0