Re: [PATCH] mm/hugetlb: restore reservation on error in hugetlb_mfill_atomic_pte() resubmission path

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 22 Mar 2026 05:21:20 +0000 David Carlier <devnexen@gmail.com> wrote:

> When the resubmission path in hugetlb_mfill_atomic_pte() allocates a new
> hugetlb folio via alloc_hugetlb_folio(), a VMA reservation is consumed. If
> copy_user_large_folio() subsequently fails, folio_put() restores the global
> hugetlb pool count through free_huge_folio(), but the per-VMA reservation
> map entry is left in an inconsistent state.
> 
> Add the missing restore_reserve_on_error() call before folio_put(), matching
> the first-attempt error path which already handles this correctly.
> 
> ...
>
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6295,6 +6295,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
>  		folio_put(*foliop);
>  		*foliop = NULL;
>  		if (ret) {
> +			restore_reserve_on_error(h, dst_vma, dst_addr, folio);
>  			folio_put(folio);
>  			goto out;
>  		}

I guess we could goto out_release_nounlock here, although I'm not sure
that improves anything - keeping track of the value of
folio_in_pagecache is rather twisty.