Messages in this thread | | | Date | Fri, 6 Apr 2018 12:35:45 +0100 | From | Alan Cox <> | Subject | Re: [PATCH] gup: return -EFAULT on access_ok failure |
| |
> 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
| |