From: syzbot <syzbot+f26d7c75c26ec19790e7@syzkaller.appspotmail.com>
To: kartikey406@gmail.com
Cc: kartikey406@gmail.com, yzbot@syzkaller.appspotmail.com,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH v2] hugetlbfs: skip VMAs without shareable locks in hugetlb_vmdelete_list
Date: Thu, 25 Sep 2025 16:18:46 -0700 [thread overview]
Message-ID: <68d5cdd6.a00a0220.303701.001e.GAE@google.com> (raw)
In-Reply-To: <20250925231839.5142-1-kartikey406@gmail.com>
> #syz test: git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
"git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git" does not look like a valid git repo address.
>
> 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+f26d7c75c26ec19790e7@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 <kartikey406@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
>
next prev parent reply other threads:[~2025-09-25 23:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250925231839.5142-1-kartikey406@gmail.com>
2025-09-25 23:18 ` [PATCH v2] hugetlbfs: skip VMAs without shareable locks in hugetlb_vmdelete_list syzbot
2025-09-25 23:18 ` syzbot [this message]
2025-09-26 3:32 Deepanshu Kartikey
2025-10-03 10:57 ` Mark Brown
2025-10-20 17:52 ` Mark Brown
2025-10-21 21:10 ` Andrew Morton
2025-10-22 11:40 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2025-10-03 11:18 Deepanshu Kartikey
2025-10-03 15:09 Deepanshu Kartikey
2025-10-03 15:09 Deepanshu Kartikey
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=68d5cdd6.a00a0220.303701.001e.GAE@google.com \
--to=syzbot+f26d7c75c26ec19790e7@syzkaller.appspotmail.com \
--cc=kartikey406@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=yzbot@syzkaller.appspotmail.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.