From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752681AbbEHJq1 (ORCPT ); Fri, 8 May 2015 05:46:27 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:35966 "EHLO mail-la0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbbEHJqZ (ORCPT ); Fri, 8 May 2015 05:46:25 -0400 From: Rasmus Villemoes To: "Reese Faucette" Cc: , Subject: Re: [PATCH] overflow check calculation in mm/mmap.c is incorrect linux-3.12.38 Organization: D03 References: <007301d08304$85881420$90983c60$@gmail.com> X-Hashcash: 1:20:150508:alan@lxorguk.ukuu.org.uk::VwQH1djh8ftfSSUa:00000000000000000000000000000000000000pk7 X-Hashcash: 1:20:150508:linux-kernel@vger.kernel.org::QKejwp5PRBFFqf++:0000000000000000000000000000000001QAP X-Hashcash: 1:20:150508:reesefaucette@gmail.com::yePNVQxrWkOKI5tU:000000000000000000000000000000000000007L17 Date: Fri, 08 May 2015 11:46:21 +0200 In-Reply-To: <007301d08304$85881420$90983c60$@gmail.com> (Reese Faucette's message of "Wed, 29 Apr 2015 22:14:19 -0700") Message-ID: <87wq0j2yhe.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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