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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux