Re: Weird code with change "mm/gup: clean up follow_pfn_pte() slightly"

[John Hubbard]

On 2/3/22 05:01, Jason Gunthorpe wrote:
...
> > > In the new branch if (pages), you set page = ERR_PTR(-EFAULT) and goto
> > > out. However, at the label out, the value of page is not used, but the
> > > return uses the variables i and ret.
> >
> > Yes, I think that the complaint is accurate. The intent of this code is
> > to return either number of pages so far (i) or ret (which should be zero
> > in this case), because we are just stopping early, rather than calling
> > this an actual error.
>
> IIRC GUP shouldn't return 0, it should return an error code, not zero.
>
> Jason

Errors work for single pages, but GUP is a multi-page API call. If it
returned an error part way through the list of pages, then callers would
have no way of knowing how many pages to release.

With that in mind, the API returns the number of pages that were
successfully pinned, if that number is > 0 (or even 0, in some cases),
even when an error has been encountered.

__get_user_pages()'s kerneldoc documentation covers it. And I see now
that it needs tweaking to include the FOLL_PIN case, but anyway:

 * Returns either number of pages pinned (which may be less than the
 * number requested), or an error. Details about the return value:
 *
 * -- If nr_pages is 0, returns 0.
 * -- If nr_pages is >0, but no pages were pinned, returns -errno.
 * -- If nr_pages is >0, and some pages were pinned, returns the number of
 *    pages pinned. Again, this may be less than nr_pages.
 * -- 0 return value is possible when the fault would need to be retried.
 *
 * The caller is responsible for releasing returned @pages, via put_page().


thanks,
--
John Hubbard
NVIDIA