Re: [PATCH RFC 05/14] mm/hugetlb: use direct assignment instead of folio_change_private()

On Fri, 31 Jul 2026 22:13:28 -0400 Zi Yan <[email protected]> wrote:

> folio_change_private() should be used along with folio_attach_private() and
> folio_detach_private(), where adding and remove ->private content requires
> folio refcount change. add_hugetlb_folio() simply sets folio->private to
> NULL without refcount manipulation. Change it to direct assignment to avoid
> semantic confusion.
> 
> It prepares for a future commit that remove PG_private.


> 
> No funtional change intended.
> 
> Assisted-by: Claude:claude-opus-4-8
> Assisted-by: Codex:gpt-5
> Signed-off-by: Zi Yan <[email protected]>
> To: Muchun Song <[email protected]>
> To: Oscar Salvador <[email protected]>
> To: Andrew Morton <[email protected]>
> Cc: David Hildenbrand <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> ---
>  mm/hugetlb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index a77c3c1cb8943..0abaeb47890cb 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1433,10 +1433,10 @@ void add_hugetlb_folio(struct hstate *h, struct folio *folio,
>  	}
>  
>  	__folio_set_hugetlb(folio);
> -	folio_change_private(folio, NULL);
> +	folio->private = NULL;
>  	/*
> -	 * We have to set hugetlb_vmemmap_optimized again as above
> -	 * folio_change_private(folio, NULL) cleared it.
> +	 * We have to set hugetlb_vmemmap_optimized again as hugetlb page flags
> +	 * are all cleared above.
>  	 */

The return value of folio_change_private() is never checked so LGTM.

In the comment, saying "above" is not very clear. How about something like:

        /*
         * The hugetlb flags live in folio->private, so the assignment
         * above cleared them all; restore hugetlb_vmemmap_optimized.
         */

With the comment clearer, feel free to add

Acked-by: Usama Arif <[email protected]>


>  	folio_set_hugetlb_vmemmap_optimized(folio);
>  
> 
> -- 
> 2.53.0
> 
>