lkml.org 
[lkml]   [2015]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] overflow check calculation in mm/mmap.c is incorrect linux-3.12.38
Date
On Thu, Apr 30 2015, "Reese Faucette" <reesefaucette@gmail.com> wrote:

> When checking for overflow, the code in mm/mmap.c compares the first byte
> *after* the end of mapped region to the start of the region instead of the
> last byte of the mapped region. This prevents mapping a region which abuts
> the end of physical space, as mmap() incorrectly rejects the region with
> -EOVERFLOW, because pgoff + (len >> PAGE_SHIFT) will be 0, which is <
> pgoff.

Note this comment elsewhere in mmap.c:

* We don't check here for the merged mmap wrapping around the end of pagecache
* indices (16TB on ia32) because do_mmap_pgoff() does not permit mmap's which
* wrap, nor mmaps which cover the final page at index -1UL.

So it seems to be by design.

But I'm also a little confused, since pgoff should be in units of pages (so a
20 bit number on 32bit), and I can't see how adding another 20 bit
number could ever make that overflow. Unless of course some magic power
ensures that pgoffs in the high half get sign-extended.

Rasmus


\
 
 \ /
  Last update: 2015-05-08 12:21    [W:0.067 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site