Re: [PATCH 2/2] mm: hugetlb: Drop refcount before freeing on memcg charge failure

[Joshua Hahn]

On Wed, 02 Sep 2026 01:22:57 -0700 Ackerley Tng via B4 Relay <devnull+ackerleytng.google.com@xxxxxxxxxx> wrote:

> From: Ackerley Tng <ackerleytng@xxxxxxxxxx>
> 
> When mem_cgroup_charge_hugetlb(folio, gfp) returns -ENOMEM, the folio has
> its refcount set to 1 via folio_ref_unfreeze(folio, 1).
> 
> The error path calls free_huge_folio(folio) directly, which expects a
> refcount of 0. Hence, VM_BUG_ON_FOLIO(folio_ref_count(folio), folio) is
> triggered.
> 
> Even with CONFIG_DEBUG_VM disabled, returning a folio with refcount 1 to
> the freelist can corrupt allocator state later.
> 
> Use folio_put(folio) instead of free_huge_folio(folio) to properly drop the
> reference before freeing it.

LGTM, thank you Ackerley!

Reviewed-by: Joshua Hahn <joshua.hahnjy@xxxxxxxxx>

> Fixes: 991135774c0e0 ("memcg/hugetlb: introduce mem_cgroup_charge_hugetlb")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Ackerley Tng <ackerleytng@xxxxxxxxxx>
> Reviewed-by: Muchun Song <muchun.song@xxxxxxxxx>
> ---
>  mm/hugetlb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 01b57f6d3b804..97c06f227ef8a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2889,7 +2889,7 @@ struct folio *hugetlb_alloc_folio(struct hstate *h,
>  	lruvec_stat_mod_folio(folio, NR_HUGETLB, nr_pages);
>  
>  	if (ret == -ENOMEM) {
> -		free_huge_folio(folio);
> +		folio_put(folio);
>  		/*
>  		 * Skip uncharging hugetlb_cgroup since the charges
>  		 * were committed to the folio and freeing the folio
> 
> -- 
> 2.55.0.970.g62bdec98f9-goog