[syzbot] [mm?] WARNING in hugetlb_vma_assert_locked

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 846bd2225ec3 Add linux-next specific files for 20250919
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=162ab8e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=135377594f35b576
dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=173b4142580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f504e2580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c53d48022f8a/disk-846bd222.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/483534e784c8/vmlinux-846bd222.xz
kernel image: https://storage.googleapis.com/syzbot-assets/721b36eec9b3/bzImage-846bd222.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: mm/hugetlb.c:368 at hugetlb_vma_assert_locked+0x1dd/0x250 mm/hugetlb.c:368, CPU#0: syz.0.366/7101
Modules linked in:
CPU: 0 UID: 0 PID: 7101 Comm: syz.0.366 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:hugetlb_vma_assert_locked+0x1dd/0x250 mm/hugetlb.c:368
Code: 2e e8 17 e8 a1 ff eb 0c e8 10 e8 a1 ff eb 05 e8 09 e8 a1 ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 f4 e7 a1 ff 90 <0f> 0b 90 eb e5 e8 e9 e7 a1 ff 90 0f 0b 90 eb da 48 c7 c1 70 0b e5
RSP: 0018:ffffc900036b7388 EFLAGS: 00010293
RAX: ffffffff821e312c RBX: 0000000000000000 RCX: ffff88807bc95ac0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff520006d6e74 R12: ffff888033642a00
R13: 1ffff1100f12319c R14: dffffc0000000000 R15: 0000000000000080
FS: 00007fa9ba21d6c0(0000) GS:ffff8881257a2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa9ba21cf98 CR3: 0000000078830000 CR4: 00000000003526f0
Call Trace:
<TASK>
huge_pmd_unshare+0x2c8/0x540 mm/hugetlb.c:7622
__unmap_hugepage_range+0x6e3/0x1aa0 mm/hugetlb.c:5901
unmap_hugepage_range+0x32e/0x410 mm/hugetlb.c:6089
hugetlb_vmdelete_list+0x171/0x1c0 fs/hugetlbfs/inode.c:494
hugetlb_vmtruncate fs/hugetlbfs/inode.c:641 [inline]
hugetlbfs_setattr+0x4d1/0x6d0 fs/hugetlbfs/inode.c:879
notify_change+0xc1a/0xf40 fs/attr.c:546
do_truncate+0x1a4/0x220 fs/open.c:68
handle_truncate fs/namei.c:3516 [inline]
do_open fs/namei.c:3899 [inline]
path_openat+0x306c/0x3830 fs/namei.c:4054
do_filp_open+0x1fa/0x410 fs/namei.c:4081
do_sys_openat2+0x121/0x1c0 fs/open.c:1435
do_sys_open fs/open.c:1450 [inline]
__do_sys_open fs/open.c:1458 [inline]
__se_sys_open fs/open.c:1454 [inline]
__x64_sys_open+0x11e/0x150 fs/open.c:1454
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa9b938eec9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fa9ba21d038 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007fa9b95e5fa0 RCX: 00007fa9b938eec9
RDX: 0000000000000100 RSI: 000000000014927e RDI: 0000200000000340
RBP: 00007fa9b9411f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fa9b95e6038 R14: 00007fa9b95e5fa0 R15: 00007ffdd776dfc8
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] hugetlbfs: skip VMAs without locks in hugetlb_vmdelete_list
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

hugetlb_vmdelete_list() can call unmap_hugepage_range() on VMAs that
have no associated lock, causing assertion failures in huge_pmd_unshare().

The function hugetlb_vma_trylock_write() returns 1 (success) even when
a VMA has neither a shareable lock nor a private lock. This allows
processing to continue, but when unmap_hugepage_range() is called, it
eventually reaches huge_pmd_unshare() which calls hugetlb_vma_assert_locked()
to verify a lock is held. The assertion fails because no lock was actually
acquired.

This results in a kernel panic:

WARNING: CPU: 1 PID: 6594 Comm: syz.0.28 Not tainted
Call Trace:
hugetlb_vma_assert_locked+0x1dd/0x250
huge_pmd_unshare+0x2c8/0x540
__unmap_hugepage_range+0x6e3/0x1aa0
unmap_hugepage_range+0x32e/0x410
hugetlb_vmdelete_list+0x189/0x1f0

Fix by skipping VMAs that have no lock before calling unmap_hugepage_range(),
as the unmap operation requires lock protection.

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/hugetlbfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9e0625167517..d2ecd83848e5 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -487,7 +487,8 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

if (!hugetlb_vma_trylock_write(vma))
continue;
-
+ if (!__vma_shareable_lock(vma) && !__vma_private_lock(vma))
+ continue;
v_start = vma_offset_start(vma, start);
v_end = vma_offset_end(vma, end);

--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Tested-by: syzbot+f26d7c...@syzkaller.appspotmail.com

Tested on:

commit: b5a4da2c Add linux-next specific files for 20250924
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11f734e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=841973c5ab4f4157

dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=1203ed34580000

Note: testing is done by a robot and is best-effort only.

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] hugetlbfs: skip non-shareable VMAs in hugetlb_vmdelete_list

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

hugetlb_vmdelete_list() processes VMAs from the i_mmap interval tree
during truncate operations. This tree should only contain shareable
(VM_MAYSHARE) mappings, as private mappings are handled through
different code paths.

However, VMAs without shareable locks can incorrectly appear in this
path, causing assertion failures in huge_pmd_unshare() when it calls
hugetlb_vma_assert_locked(). The assertion expects a lock to be held
for the VMA being processed.

When hugetlb_vma_trylock_write() succeeds but the VMA has no shareable
lock (__vma_shareable_lock returns false), the code proceeds to call
unmap_hugepage_range(). Inside this function, huge_pmd_unshare() calls
hugetlb_vma_assert_locked() which fails because no lock is actually held,
resulting in a kernel panic:

WARNING: CPU: 1 PID: 6594 Comm: syz.0.28 Not tainted
Call Trace:
hugetlb_vma_assert_locked+0x1dd/0x250
huge_pmd_unshare+0x2c8/0x540
__unmap_hugepage_range+0x6e3/0x1aa0
unmap_hugepage_range+0x32e/0x410
hugetlb_vmdelete_list+0x189/0x1f0

Fix by skipping VMAs that don't have a shareable lock. These VMAs
should not be in the shared mapping deletion path and are handled
by separate code paths for private mappings.

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/hugetlbfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c

index 9e0625167517..9ba98cab3388 100644

--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -487,7 +487,8 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

if (!hugetlb_vma_trylock_write(vma))
continue;
-

+ if (!__vma_shareable_lock(vma))

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Tested-by: syzbot+f26d7c...@syzkaller.appspotmail.com

Tested on:

commit: b5a4da2c Add linux-next specific files for 20250924
git tree: linux-next

console output: https://syzkaller.appspot.com/x/log.txt?x=13e0b4e2580000

kernel config: https://syzkaller.appspot.com/x/.config?x=841973c5ab4f4157
dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=14362f12580000

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH v2] hugetlbfs: skip VMAs without shareable locks in hugetlb_vmdelete_list

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

hugetlb_vmdelete_list() uses trylock to acquire VMA locks during truncate
operations. As per the original design in commit 40549ba8f8e0 ("hugetlb:
use new vma_lock for pmd sharing synchronization"), if the trylock fails
or the VMA has no lock, it should skip that VMA. Any remaining mapped
pages are handled by remove_inode_hugepages() which is called after
hugetlb_vmdelete_list() and uses proper lock ordering to guarantee
unmapping success.

Currently, when hugetlb_vma_trylock_write() returns success (1) for VMAs
without shareable locks, the code proceeds to call unmap_hugepage_range().
This causes assertion failures in huge_pmd_unshare() → hugetlb_vma_assert_locked()
because no lock is actually held:

WARNING: CPU: 1 PID: 6594 Comm: syz.0.28 Not tainted
Call Trace:
hugetlb_vma_assert_locked+0x1dd/0x250
huge_pmd_unshare+0x2c8/0x540
__unmap_hugepage_range+0x6e3/0x1aa0
unmap_hugepage_range+0x32e/0x410
hugetlb_vmdelete_list+0x189/0x1f0

Fix by checking for shareable lock before attempting trylock, avoiding
both the assertion failure and potential lock leaks from skipping VMAs
after locks are acquired.

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7

Fixes: 40549ba8f8e0 ("hugetlb: use new vma_lock for pmd sharing synchronization")

Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>

---

Changes in v2:
- Check for shareable lock before trylock to avoid lock leaks (Andrew Morton)
- Add comment explaining why non-shareable VMAs are skipped (Andrew Morton)
---
fs/hugetlbfs/inode.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9e0625167517..44943e97adb0 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -484,6 +484,13 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,
vma_interval_tree_foreach(vma, root, start, end ? end - 1 : ULONG_MAX) {
unsigned long v_start;
unsigned long v_end;
+ /*
+ * Skip VMAs without shareable locks. Per the design in commit
+ * 40549ba8f8e0, these will be handled by remove_inode_hugepages()
+ * called after this function with proper locking.
+ */

+ if (!__vma_shareable_lock(vma))
+ continue;

if (!hugetlb_vma_trylock_write(vma))
continue;
--
2.43.0

[syzbot]

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH v2] hugetlbfs: skip VMAs without shareable locks in hugetlb_vmdelete_list
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

hugetlb_vmdelete_list() uses trylock to acquire VMA locks during truncate
operations. As per the original design in commit 40549ba8f8e0 ("hugetlb:
use new vma_lock for pmd sharing synchronization"), if the trylock fails
or the VMA has no lock, it should skip that VMA. Any remaining mapped
pages are handled by remove_inode_hugepages() which is called after
hugetlb_vmdelete_list() and uses proper lock ordering to guarantee
unmapping success.

Currently, when hugetlb_vma_trylock_write() returns success (1) for VMAs
without shareable locks, the code proceeds to call unmap_hugepage_range().
This causes assertion failures in huge_pmd_unshare() → hugetlb_vma_assert_locked()
because no lock is actually held:

WARNING: CPU: 1 PID: 6594 Comm: syz.0.28 Not tainted
Call Trace:
hugetlb_vma_assert_locked+0x1dd/0x250
huge_pmd_unshare+0x2c8/0x540
__unmap_hugepage_range+0x6e3/0x1aa0
unmap_hugepage_range+0x32e/0x410
hugetlb_vmdelete_list+0x189/0x1f0

Fix by using goto to ensure locks acquired by trylock are always released, even
when skipping VMAs without shareable locks.

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
Fixes: 40549ba8f8e0 ("hugetlb: use new vma_lock for pmd sharing synchronization")

Suggested-by: Andrew Morton <ak...@linux-foundation.org>

Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>

---
Changes in v2:

- Use goto to unlock after trylock, avoiding lock leaks (Andrew Morton)

- Add comment explaining why non-shareable VMAs are skipped (Andrew Morton)
---

fs/hugetlbfs/inode.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9e0625167517..9fa7c72ac1a6 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -488,6 +488,14 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,
if (!hugetlb_vma_trylock_write(vma))
continue;

+ /*
+ * Skip VMAs without shareable locks. Per the design in commit
+ * 40549ba8f8e0, these will be handled by remove_inode_hugepages()
+ * called after this function with proper locking.
+ */
+ if (!__vma_shareable_lock(vma))

+ goto skip;
+

v_start = vma_offset_start(vma, start);
v_end = vma_offset_end(vma, end);

@@ -498,7 +506,8 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,
* vmas. Therefore, lock is not held when calling
* unmap_hugepage_range for private vmas.
*/
- hugetlb_vma_unlock_write(vma);
+skip:
+ hugetlb_vma_unlock_write(vma);
}
}

--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Tested-by: syzbot+f26d7c...@syzkaller.appspotmail.com

Tested on:

commit: 8e2755d7 Add linux-next specific files for 20250925
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16f1af12580000
kernel config: https://syzkaller.appspot.com/x/.config?x=1ba7bd7be9b0a083

dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=123474e2580000

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Tested-by: syzbot+f26d7c...@syzkaller.appspotmail.com

Tested on:

commit: 8e2755d7 Add linux-next specific files for 20250925
git tree: linux-next

console output: https://syzkaller.appspot.com/x/log.txt?x=14871142580000

kernel config: https://syzkaller.appspot.com/x/.config?x=1ba7bd7be9b0a083
dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=15319d34580000

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] hugetlbfs: skip PMD unsharing when shareable lock unavailable

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

When hugetlb_vmdelete_list() cannot acquire the shareable lock for a VMA,
the original code skipped the entire VMA, leaving pages unmapped. This
caused a regression where pages were not freed during fallocate(PUNCH_HOLE)
operations, as reported by Mark Brown.

The issue occurs because:
1. hugetlb_vmdelete_list() tries to acquire the VMA lock
2. For shareable VMAs, this includes the shareable lock via
hugetlb_vma_trylock_write()
3. If successful and VMA is shareable type, we have the shareable lock
4. huge_pmd_unshare() requires this lock and asserts it is held

The previous fix (dd83609b8898) avoided the assertion by skipping entire
VMAs without shareable locks, but this prevented pages from being unmapped
and freed, breaking PUNCH_HOLE behavior.

This fix takes a different approach: instead of skipping the VMA entirely,
we skip only the PMD unsharing operation when we don't have the required
lock, while still proceeding with page unmapping. This is safe because:
- PMD unsharing is an optimization to reduce shared page table overhead
- Page unmapping can proceed safely with just the VMA write lock
- Pages get freed immediately as expected by PUNCH_HOLE callers

We add a new ZAP_FLAG_NO_UNSHARE flag to communicate to
__unmap_hugepage_range() that it should skip huge_pmd_unshare() while
still clearing page table entries and freeing pages.

Fixes: dd83609b8898 ("hugetlbfs: skip VMAs without shareable locks in hugetlb_vmdelete_list")
Reported-by: Mark Brown <bro...@kernel.org>
Link: https://lore.kernel.org/all/20251003150956.287...@gmail.com/T/
Signed-off-by: Deepanshu Kartikey <Karti...@gmail.com>
---
fs/hugetlbfs/inode.c | 22 ++++++++++++----------
include/linux/mm.h | 2 ++
mm/hugetlb.c | 3 ++-
3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9c94ed8c3ab0..519497bc1045 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -474,29 +474,31 @@ hugetlb_vmdelete_list(struct rb_root_cached *root, pgoff_t start, pgoff_t end,

vma_interval_tree_foreach(vma, root, start, end ? end - 1 : ULONG_MAX) {
unsigned long v_start;
unsigned long v_end;

+ bool have_shareable_lock;
+ zap_flags_t local_flags = zap_flags;

if (!hugetlb_vma_trylock_write(vma))
continue;
-
+

+ have_shareable_lock = __vma_shareable_lock(vma);
+
/*
- * Skip VMAs without shareable locks. Per the design in commit
- * 40549ba8f8e0, these will be handled by remove_inode_hugepages()
- * called after this function with proper locking.
+ * If we can't get the shareable lock, set ZAP_FLAG_NO_UNSHARE
+ * to skip PMD unsharing. We still proceed with unmapping to
+ * ensure pages are properly freed, which is critical for punch
+ * hole operations that expect immediate page freeing.
*/
- if (!__vma_shareable_lock(vma))
- goto skip;
-
+ if (!have_shareable_lock)
+ local_flags |= ZAP_FLAG_NO_UNSHARE;

v_start = vma_offset_start(vma, start);
v_end = vma_offset_end(vma, end);

- unmap_hugepage_range(vma, v_start, v_end, NULL, zap_flags);
-
+ unmap_hugepage_range(vma, v_start, v_end, NULL, local_flags);
/*
* Note that vma lock only exists for shared/non-private

* vmas. Therefore, lock is not held when calling
* unmap_hugepage_range for private vmas.
*/

-skip:
hugetlb_vma_unlock_write(vma);
}
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 06978b4dbeb8..9126ab44320d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2395,6 +2395,8 @@ struct zap_details {
#define ZAP_FLAG_DROP_MARKER ((__force zap_flags_t) BIT(0))
/* Set in unmap_vmas() to indicate a final unmap call. Only used by hugetlb */
#define ZAP_FLAG_UNMAP ((__force zap_flags_t) BIT(1))
+/* Skip PMD unsharing when unmapping hugetlb ranges without shareable lock */
+#define ZAP_FLAG_NO_UNSHARE ((__force zap_flags_t) BIT(2))

#ifdef CONFIG_SCHED_MM_CID
void sched_mm_cid_before_execve(struct task_struct *t);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6cac826cb61f..c4257aa568fe 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5885,7 +5885,8 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
}

ptl = huge_pte_lock(h, mm, ptep);
- if (huge_pmd_unshare(mm, vma, address, ptep)) {
+ if (!(zap_flags & ZAP_FLAG_NO_UNSHARE) &&
+ huge_pmd_unshare(mm, vma, address, ptep)) {
spin_unlock(ptl);
tlb_flush_pmd_range(tlb, address & PUD_MASK, PUD_SIZE);
force_flush = true;
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f26d7c...@syzkaller.appspotmail.com
Tested-by: syzbot+f26d7c...@syzkaller.appspotmail.com

Tested on:

commit: 47a8d4b8 Add linux-next specific files for 20251003
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16b765cd980000
kernel config: https://syzkaller.appspot.com/x/.config?x=5cc2d3410fac6d84

dashboard link: https://syzkaller.appspot.com/bug?extid=f26d7c75c26ec19790e7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=10cb9334580000