Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: Muchun Song <songmuchun@bytedance.com>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	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: Wed, 11 Nov 2026 16:32:14 +0800	[thread overview]
Message-ID: <C58DC8B2-F2F6-49F0-A9D4-079FA66B69C9@linux.dev> (raw)
In-Reply-To: <sashiko-outbox-206969@kernel.org>



> On Nov 10, 2026, at 20:01, sashiko-bot@kernel.org wrote:
> 
> 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?

A valid point, I'll fix it ASAP.

THanks.

> 
> 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-11  8:32 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
2026-11-11  8:32   ` Muchun Song [this message]

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=C58DC8B2-F2F6-49F0-A9D4-079FA66B69C9@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=joao.m.martins@oracle.com \
    --cc=linux-mm@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox