Re: [PATCH v2 2/4] mm/hugetlb: Refactor unmap_hugepage_range() to take folio instead of page

[Matthew Wilcox <willy@infradead.org>]

On Fri, Apr 18, 2025 at 09:57:40AM -0700, nifan.cxl@gmail.com wrote:
>  void unmap_hugepage_range(struct vm_area_struct *,
> -			  unsigned long, unsigned long, struct page *,
> +			  unsigned long, unsigned long, struct folio *folio,

I'm fine with leaving the vma and folio unnamed, but it is a crime
against our fellow programmers to leave the two 'unsigned long's
unnamed.  What the hell are they?

>  void unmap_hugepage_range(struct vm_area_struct *vma, unsigned long start,
> -			  unsigned long end, struct page *ref_page,
> +			  unsigned long end, struct folio *ref_folio,

... start and end.  I'd happily see a patch which only named those
parameters and left the struct folio unnamed.

> -	__unmap_hugepage_range(&tlb, vma, start, end, ref_page, zap_flags);
> +	__unmap_hugepage_range(&tlb, vma, start, end,
> +			       folio_page(ref_folio, 0), zap_flags);

I do not like this.  Why should we pass in the first page here?  It
seems to me that this is just "Now we will call a function which still
takes a struct page", and we *SHOULD* use &folio->page here to indicate
that we just haven't done the conversion yet.