All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Muchun Song" <songmuchun@bytedance.com>,
	"Oscar Salvador" <osalvador@suse.de>,
	"Andrew Morton" <akpm@linux-foundation.org>
Cc: "Muchun Song" <muchun.song@linux.dev>,
	"David Hildenbrand" <david@kernel.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Joao Martins" <joao.m.martins@oracle.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm/hugetlb_vmemmap: fix PMD split TLB flush race
Date: Tue, 10 Nov 2026 12:01:22 +0000	[thread overview]
Message-ID: <sashiko-outbox-206969@kernel.org> (raw)
In-Reply-To: <20261110112456.62827-1-songmuchun@bytedance.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] mm/hugetlb_vmemmap: deadlock from GFP_KERNEL alloc under
  init_mm.mmap_lock
--

commit c4de2ad9c999ebd1524c99a20d1c19a13ab7ec8f
Author: Muchun Song <muchun.song@linux.dev>

mm/hugetlb_vmemmap: fix PMD split TLB flush race

This commit serializes batched vmemmap PMD splitting and its final TLB flush
against concurrent PTE remapping using init_mm.mmap_lock.

> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index ba8e11e399b24..ba6559bef742a 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
[ ... ]
> @@ -559,6 +565,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
>  	if (list_empty(folio_list))
>  		return;
>  
> +	mmap_write_lock(&init_mm);
>  	list_for_each_entry(folio, folio_list, lru) {
>  		int ret;
>  

[Severity: High]
Can holding init_mm.mmap_lock for write across hugetlb_vmemmap_pteify_folio()
deadlock in memory reclaim?

hugetlb_vmemmap_pteify_folio() walks the kernel page tables and calls
vmemmap_split_pmd() -> pte_alloc_one_kernel(&init_mm), which allocates a page
table with GFP_PGTABLE_KERNEL (GFP_KERNEL).  Reclaim shrinkers such as
ttm_pool_shrinker_scan() take mmap_read_lock(&init_mm) when restoring direct
map attributes via set_pages_wb() -> change_page_attr_set_clr():

hugetlb_vmemmap_optimize_folios()
  mmap_write_lock(&init_mm)
  hugetlb_vmemmap_pteify_folio()
    ...
      vmemmap_split_pmd()
        pte_alloc_one_kernel(&init_mm)  /* GFP_KERNEL */
          <direct reclaim>
            ttm_pool_shrinker_scan()
              ...
                change_page_attr_set_clr()
                  mmap_read_lock(&init_mm)  <-- self-deadlock

Because fs_reclaim nests outside init_mm.mmap_lock, this also triggers a
lockdep splat on the first vmemmap PMD split (including under
mmap_read_lock(&init_mm) in vmemmap_optimize_folio()) and can ABBA deadlock
against kswapd.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110112456.62827-1-songmuchun@bytedance.com?part=1


  reply	other threads:[~2026-11-10 12:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 11:24 [PATCH] mm/hugetlb_vmemmap: fix PMD split TLB flush race Muchun Song
2026-11-10 12:01 ` sashiko-bot [this message]
2026-11-11  8:32   ` Muchun Song

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=sashiko-outbox-206969@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=joao.m.martins@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=rppt@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=songmuchun@bytedance.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.