Re: [PATCH V1 1/9] mm/gup: repin_folio_unhugely

[Jason Gunthorpe <jgg@nvidia.com>]

On Sat, Sep 14, 2024 at 06:05:50AM -0700, Steve Sistare wrote:
> diff --git a/mm/gup.c b/mm/gup.c
> index 947881ff..f8f3f2a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -3720,3 +3720,21 @@ long memfd_pin_folios(struct file *memfd, loff_t start, loff_t end,
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(memfd_pin_folios);
> +
> +/**
> + * repin_folio_unhugely() - repin a folio at small page granularity
> + * @folio: the folio to repin
> + * @npin:  the number of pages pinned in the folio
> + *
> + * Given a huge page folio that is already pinned, and the number of small
> + * pages that are pinned in it, adjust the pincount to reflect small-page
> + * granularity.  Each small page can later be unpinned individually.
> + */

I think the language choice here is probably not entirely consistent
with the rest of the code..

Maybe 

 folio_split_user_page_pin(folio, npages)
 @npages: The new number of pages the folio pin reference should hold

 Given a high order folio that is already pinned adjust the reference
 count to allow unpin_user_page_range() and related to be called on a
 the folio. npages is the number of pages that will be passed to a
 future unpin_user_page_range().

Which anchors it in the purpose a little more

The implementation looked OK to me

Jason