Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

[John Hubbard]

On 2020-05-07 03:32, Souptick Joarder wrote:
...
> > OK, so no real problem with any of these callers. I still don't see a
> > justification for the churn you suggest... Auditting all those code sites
> > is going to be pretty tedious.
>
> I try to audit all 42 callers of {get|pin}_user_pages_fast() and
> figure out these 5 callers
> which need to be updated and I think, other callers of
> {get|pin}_user_pages_fast() will not be
> effected.
>
> But I didn't go through other variants of gup/pup except
> {get|pin}_user_pages_fast().


I feel the need to apologize for suggesting that a change to -EINVAL
would help. :)

If you change what the return value means, but only apply it the
gup/pup _fast() variants of this API set, that would make
the API significantly *worse*.

Also, no one has been able to come up with a scenario in which the call
sites actually have a problem handling return values of zero. In fact,
on the contrary: there are call site where returning 0 after being
requested to pin zero pages, helps simplify the code. For example, if
they're just doing math such as "if(nr_expected != nr_pages_pinned) ...".


This looks like a complete dead end, sorry.

thanks,
--
John Hubbard
NVIDIA