On Fri, 3 Aug 2018 15:47:01 +0300 Alexey Dobriyan <adobriyan@xxxxxxxxx> wrote: > On Thu, Aug 02, 2018 at 02:02:22PM -0700, Andrew Morton wrote: > > On Thu, 2 Aug 2018 09:47:52 -0700 Yang Shi <shy828301@xxxxxxxxx> wrote: > > > > > On Thu, Aug 2, 2018 at 12:37 AM, <chenjie6@xxxxxxxxxx> wrote: > > > > From: chen jie <chen jie@chenjie6@xxxxxxxxx> > > > > > > > > ioremap_prot can return NULL which could lead to an oops > > > > > > What oops? You'd better to have the oops information in your commit log. > > > > Doesn't matter much - the code is clearly buggy. > > > > Looking at the callers, I have suspicions about > > fs/proc/base.c:environ_read(). It's assuming that access_remote_vm() > > returns an errno. But it doesn't - it returns number of bytes copied. > > > > Alexey, could you please take a look? While in there, I'd suggest > > adding some return value documentation to __access_remote_vm() and > > access_remote_vm(). Thanks. > > This is true: remote VM accessors return number of bytes copied > but ->access returns len/-E. Returning "int" is deceptive. It's more than deceptive - it's flat-out buggy for >4G copy attempts. And highly dubious for 2G-4G copies, where it might return a negative int. I suppose that access_remote_vm() should strictly return a ptrdiff_t, but we hardly ever use that. size_t will do.
