When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due
to a PMD check failure, the pgtable allocated earlier via
pte_alloc_one() is never freed, causing a memory leak.

Add a pte_free() call in the unlock_abort error path to release
the pgtable before returning.

Signed-off-by: Sunny Patel <nueralspacetech@gmail.com>
---
 mm/migrate_device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index fbfe5715f635..457bab5c7c31 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -893,6 +893,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
 
 unlock_abort:
 	spin_unlock(ptl);
+	pte_free(vma->vm_mm, pgtable);
 abort:
 	for (i = 0; i < HPAGE_PMD_NR; i++)
 		src[i] &= ~MIGRATE_PFN_MIGRATE;
-- 
2.43.0

Hi, Sunny,

Thanks for working on this!

Sunny Patel <nueralspacetech@gmail.com> writes:

> When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due
> to a PMD check failure, the pgtable allocated earlier via
> pte_alloc_one() is never freed, causing a memory leak.
>
> Add a pte_free() call in the unlock_abort error path to release
> the pgtable before returning.
>
> Signed-off-by: Sunny Patel <nueralspacetech@gmail.com>
> ---
>  mm/migrate_device.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index fbfe5715f635..457bab5c7c31 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -893,6 +893,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
>  
>  unlock_abort:
>  	spin_unlock(ptl);
> +	pte_free(vma->vm_mm, pgtable);
>  abort:
>  	for (i = 0; i < HPAGE_PMD_NR; i++)
>  		src[i] &= ~MIGRATE_PFN_MIGRATE;

Is it better to use guard based automatic memory freeing?

And check whether guard can help unlock case too?

---
Best Regards,
Huang, Ying

On 25 Apr 2026, at 9:44, Sunny Patel wrote:

> When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due
> to a PMD check failure, the pgtable allocated earlier via
> pte_alloc_one() is never freed, causing a memory leak.
>
> Add a pte_free() call in the unlock_abort error path to release
> the pgtable before returning.
>
> Signed-off-by: Sunny Patel <nueralspacetech@gmail.com>
> ---
>  mm/migrate_device.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index fbfe5715f635..457bab5c7c31 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -893,6 +893,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
>
>  unlock_abort:
>  	spin_unlock(ptl);
> +	pte_free(vma->vm_mm, pgtable);
>  abort:
>  	for (i = 0; i < HPAGE_PMD_NR; i++)
>  		src[i] &= ~MIGRATE_PFN_MIGRATE;
> -- 
> 2.43.0

Actually,

I think the "goto abort" above pmd_lock() need to do pte_free():

        if (folio_is_device_private(folio)) {
			...
        } else {
                if (folio_is_zone_device(folio) &&
                    !folio_is_device_coherent(folio)) {
                        goto abort; <-- this one
                }
			...
        }

The lock is not taken yet, so you might need to add a pte_free() before
goto abort.

--
Best Regards,
Yan, Zi

On Sat, 25 Apr 2026 10:21:01 -0400, Zi Yan wrote:
> I think the "goto abort" above pmd_lock() need to do pte_free():
>
>         if (folio_is_device_private(folio)) {
>                         ...
>         } else {
>                 if (folio_is_zone_device(folio) &&
>                     !folio_is_device_coherent(folio)) {
>                         goto abort; <-- this one
>                 }
>                         ...
>         }
>
> The lock is not taken yet, so you might need to add a pte_free()
> before goto abort.

You are right. The pgtable is allocated before this check and
the lock has not been taken yet at this point, so goto
unlock_abort would be incorrect here. A pte_free() call is
needed before this goto abort.

Sent v2 with the changes.
https://lore.kernel.org/linux-mm/20260427063729.17294-1-nueralspacetech@gmail.com/

Thanks for catching this.

Regards,
Sunny Patel

On 25 Apr 2026, at 9:44, Sunny Patel wrote:

> When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due
> to a PMD check failure, the pgtable allocated earlier via
> pte_alloc_one() is never freed, causing a memory leak.
>
> Add a pte_free() call in the unlock_abort error path to release
> the pgtable before returning.
>
> Signed-off-by: Sunny Patel <nueralspacetech@gmail.com>
> ---
>  mm/migrate_device.c | 1 +
>  1 file changed, 1 insertion(+)
>
LGTM.

Acked-by: Zi Yan <ziy@nvidia.com>

--
Best Regards,
Yan, Zi