From: Andrew Morton <akpm@linux-foundation.org>
To: Jane Chu <jane.chu@oracle.com>
Cc: david@redhat.com, harry.yoo@oracle.com, osalvador@suse.de,
liushixin2@huawei.com, muchun.song@linux.dev, jannh@google.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count
Date: Mon, 15 Sep 2025 20:08:15 -0700 [thread overview]
Message-ID: <20250915200815.e2b844e0a3291fa994d333b4@linux-foundation.org> (raw)
In-Reply-To: <20250916004520.1604530-1-jane.chu@oracle.com>
On Mon, 15 Sep 2025 18:45:20 -0600 Jane Chu <jane.chu@oracle.com> wrote:
> 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] <TASK>
> [ 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.
Thanks. I dropped the v2 patch from mm-hotfixes-stable and added this.
> Fixes: 59d9094df3d79 ("mm: hugetlb: independent PMD page table shared count")
> Signed-off-by: Jane Chu <jane.chu@oracle.com>
> Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
> ---
> include/linux/mm_types.h | 5 +++++
> mm/hugetlb.c | 15 +++++----------
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
It's conventional (and useful) to explain (beneath the "---") what
changed since the previous version.
Here's the v2->v3 diff, which appears to be based on David's review
comments:
--- a/include/linux/mm_types.h~mm-hugetlb-fix-copy_hugetlb_page_range-to-use-pt_share_count
+++ a/include/linux/mm_types.h
@@ -631,6 +631,11 @@ static inline int ptdesc_pmd_pts_count(s
{
return atomic_read(&ptdesc->pt_share_count);
}
+
+static inline bool ptdesc_pmd_is_shared(struct ptdesc *ptdesc)
+{
+ return !!ptdesc_pmd_pts_count(ptdesc);
+}
#else
static inline void ptdesc_pmd_pts_init(struct ptdesc *ptdesc)
{
--- a/mm/hugetlb.c~mm-hugetlb-fix-copy_hugetlb_page_range-to-use-pt_share_count
+++ a/mm/hugetlb.c
@@ -5595,8 +5595,8 @@ int copy_hugetlb_page_range(struct mm_st
}
#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
- /* If the pagetables are shared don't copy or take references. */
- if (ptdesc_pmd_pts_count(virt_to_ptdesc(dst_pte)) > 0) {
+ /* If the pagetables are shared, there is nothing to do */
+ if (ptdesc_pmd_is_shared(virt_to_ptdesc(dst_pte))) {
addr |= last_addr_mask;
continue;
}
@@ -7597,7 +7597,7 @@ int huge_pmd_unshare(struct mm_struct *m
hugetlb_vma_assert_locked(vma);
if (sz != PMD_SIZE)
return 0;
- if (!ptdesc_pmd_pts_count(virt_to_ptdesc(ptep)))
+ if (!ptdesc_pmd_is_shared(virt_to_ptdesc(ptep)))
return 0;
pud_clear(pud);
_
next prev parent reply other threads:[~2025-09-16 3:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 0:45 Jane Chu
2025-09-16 3:08 ` Andrew Morton [this message]
2025-09-16 18:12 ` jane.chu
2025-09-17 7:40 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250915200815.e2b844e0a3291fa994d333b4@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=harry.yoo@oracle.com \
--cc=jane.chu@oracle.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushixin2@huawei.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox