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
