Re: [PATCH] gup: return -EFAULT on access_ok failure

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

 



> so an error on the 1st page gets propagated to the caller,
> and that get_user_pages_unlocked eventually calls __get_user_pages
> so it does return an error sometimes.
> 
> Would it be correct to apply the second part of the patch then
> (pasted below for reference) or should get_user_pages_fast
> and all its callers be changed to return 0 on error instead?

0 isn't an error. As SuS sees it (ie from the userspace end of the pile)

returning the number you asked for means it worked

returning a smaller number means it worked partially and that much was
consumed (or in some cases more and the rest if so was lost - depends
what you are reading/writing)

returning 0 means you read nothing as you were at the end of file

returning an error code means it broke, or you should try again
(EAGAIN/EWOULDBLOCK)

The ugly bit there is the try-again semantics needs to exactly match the
attached poll() behaviour or you get busy loops.

Alan



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]