From: Lorenzo Stoakes <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>, Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH mm-hotfixes] mm/hugetlb: avoid false positive lockdep assertion
Date: Wed, 13 May 2026 12:02:31 +0100 [thread overview]
Message-ID: <agRZ_DdOHzDELWOg@lucifer> (raw)
In-Reply-To: <291cd4df-7c52-426e-a8cc-b0cf77654c52@kernel.org>
On Wed, May 13, 2026 at 12:15:23PM +0200, David Hildenbrand (Arm) wrote:
> On 5/13/26 10:56, Lorenzo Stoakes wrote:
> > Commit 081056dc00a2 ("mm/hugetlb: unshare page tables during VMA split, not
> > before") changed the locking model around hugetlbfs PMD unsharing on VMA
> > split, but did not update the function which asserts the locks,
> > hugetlb_vma_assert_locked().
> >
> > This function asserts that either the hugetlb VMA lock is held (if a shared
> > mapping) or that the reservation map lock is held (if private).
> >
> > If you get an unfortunate race between something which results in one of
> > these locks being released and a hugetlb split and you have CONFIG_LOCKDEP
>
> "hugetlb split": I assume you used that terminology because of hugetlb_split().
> Which is all just rather nasty #justhugetlbthings
>
> "hugetlb VMA split" is probably easier to get.
Yeah another one of those overloaded terms :>)
Andrew - do you mind doing s/hugetlb split/hugetlb VMA split/? Thanks!
>
> > enabled, you can therefore see a false positive assertion arise when there
> > is in fact no issue.
> >
> > Since this change introduced a new take_locks parameter to
> > hugetlb_unshare_pmds(), which, when set to false, indicates that locking is
> > sufficient, simply pass this to the unsharing logic and predicate the
> > lock assertions on this.
> >
> > This is safe, as we already asserted the file rmap lock and the VMA write
> > lock prior to this (implying exclusive mmap write lock), so we cannot be
> > raced by either rmap or page fault page table walkers which the asserted
> > locks are intended to protect against (we don't mind GUP-fast).
> >
> > Separate out huge_pmd_unshare() into __huge_pmd_unshare() to add a
> > check_locks parameter, and update hugetlb_unshare_pmds() to pass this
> > parameter to it.
> >
> > This leaves all other callers of huge_pmd_unshare() still correctly
> > asserting the locks.
> >
> > The below reproducer will trigger the assert in a kernel with
> > CONFIG_LOCKDEP enabled by racing process teardown (which will release the
> > hugetlb lock) against a hugetlb split.
> >
> > void execute_one(void)
> > {
> > void *ptr;
> > pid_t pid;
> >
> > /*
> > * Create a hugetlb mapping spanning a PUD entry.
> > *
> > * We force the hugetlb page allocation with populate and
> > * noreserve.
> > *
> > * |---------------------|
> > * | |
> > * |---------------------|
> > * 0 PUD boundary
> > */
> > ptr = mmap(0, PUD_SIZE, PROT_READ | PROT_WRITE,
> > MAP_FIXED | MAP_SHARED | MAP_ANON |
> > MAP_NORESERVE | MAP_HUGETLB | MAP_POPULATE,
> > -1, 0);
> > if (ptr == MAP_FAILED) {
> > perror("mmap");
> > exit(EXIT_FAILURE);
> > }
> >
> > /*
> > * Fork but with a bogus stack pointer so we try to execute code in
> > * a non-VM_EXEC VMA, causing segfault + teardown via exit_mmap().
> > *
> > * The clone will cause PMD page table sharing between the
> > * processes first via:
> > * copy_process() -> ... -> huge_pte_alloc() -> huge_pmd_share()
> > *
> > * Then tear down and release the hugetlb 'VMA' lock via:
> > * exit_mmap() -> ... -> vma_close() -> hugetlb_vma_lock_free()
> > */
> > pid = syscall(__NR_clone, 0, 2 * PMD_SIZE, 0, 0, 0);
> > if (pid < 0) {
> > perror("clone");
> > exit(EXIT_FAILURE);
> > } if (pid == 0) {
> > /* Pop stack... */
> > return;
> > }
> >
> > /*
> > * We are the parent process.
> > *
> > * Race the child process's teardown with a PMD unshare.
> > *
> > * We do this by triggering:
> > *
> > * __split_vma() -> hugetlb_split() -> hugetlb_unshare_pmds()
> > *
> > * Which, importantly, doesn't hold the hugetlb VMA lock (nor can
> > * it), meaning we assert in hugetlb_vma_assert_locked().
> > *
> > * .
> > * |----------.----------|
> > * | . |
> > * |----------.----------|
> > * 0 . PUD boundary
> > */
> > mmap(0, PUD_SIZE / 2, PROT_READ | PROT_WRITE,
> > MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0);
> > }
> >
> > int main(void)
> > {
> > int i;
> >
> > /* Kick off fork children. */
> > for (i = 0; i < NUM_FORKS; i++) {
> > pid_t pid = fork();
> >
> > if (pid < 0) {
> > perror("fork");
> > exit(EXIT_FAILURE);
> > }
> >
> > /* Fork children do their work and exit. */
> > if (!pid) {
> > int j;
> >
> > for (j = 0; j < NUM_ITERS; j++)
> > execute_one();
> > return EXIT_SUCCESS;
> > }
> > }
> >
> > /* If we succeeded, wait on children. */
> > for (i = 0; i < NUM_FORKS; i++)
> > wait(NULL);
> >
> > return EXIT_SUCCESS;
> > }
> >
> > Fixes: 081056dc00a2 ("mm/hugetlb: unshare page tables during VMA split, not before")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
>
> LGTM, all rather nasty with "take_locks" parameters ...
Yeah it is, but since that's already there, I guess this is the easiest way to
do it! :)
>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cheers!
>
> --
> Cheers,
>
> David
next prev parent reply other threads:[~2026-05-13 11:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 8:56 [PATCH mm-hotfixes] mm/hugetlb: avoid false positive lockdep assertion Lorenzo Stoakes
2026-05-13 10:15 ` David Hildenbrand (Arm)
2026-05-13 11:02 ` Lorenzo Stoakes [this message]
2026-05-13 11:30 ` Oscar Salvador
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=agRZ_DdOHzDELWOg@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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