From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932141AbbEMQ66 (ORCPT ); Wed, 13 May 2015 12:58:58 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:35198 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752555AbbEMQ6z (ORCPT ); Wed, 13 May 2015 12:58:55 -0400 From: "Reese Faucette" To: "'Rasmus Villemoes'" Cc: , References: <007301d08304$85881420$90983c60$@gmail.com> <87wq0j2yhe.fsf@rasmusvillemoes.dk> In-Reply-To: <87wq0j2yhe.fsf@rasmusvillemoes.dk> Subject: RE: [PATCH] overflow check calculation in mm/mmap.c is incorrect linux-3.12.38 Date: Wed, 13 May 2015 09:58:52 -0700 Message-ID: <003d01d08d9e$17f55e50$47e01af0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKJ1bGJbP1+upGFwtYMYQWEPkD81QHtDW/nm/XWdkA= Content-Language: en-us Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rasmus- I think you're right - I was not paying close enough attention. In this case, I think the real culprit appears to be something like libc incorrectly sign-extending the mmap() offset argument. Calling mmap() with an offset of 0xf80000000 is resulting in a pg_off of 0xffff8000 when the syscall wrappers convert the mmap() call to mmap_pgoff(). This is on MIPS linux - I'll dig further on the user side to see why the offset is being sign extended. The proper casts *seem* to be in place in libc, but its plainly not doing what it's supposed to. -reese > -----Original Message----- > From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk] > Sent: Friday, May 08, 2015 2:46 AM > To: Reese Faucette > Cc: linux-kernel@vger.kernel.org; alan@lxorguk.ukuu.org.uk > Subject: Re: [PATCH] overflow check calculation in mm/mmap.c is incorrect > linux-3.12.38 > > On Thu, Apr 30 2015, "Reese Faucette" 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