From owner-freebsd-bugs@FreeBSD.ORG  Sun Jun 29 17:01:59 2008
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id C641C106567E;
	Sun, 29 Jun 2008 17:01:59 +0000 (UTC) (envelope-from das@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 931448FC26;
	Sun, 29 Jun 2008 17:01:59 +0000 (UTC) (envelope-from das@FreeBSD.org)
Received: from freefall.freebsd.org (das@localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5TH1xxp066703;
	Sun, 29 Jun 2008 17:01:59 GMT
	(envelope-from das@freefall.freebsd.org)
Received: (from das@localhost)
	by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5TH1xec066699;
	Sun, 29 Jun 2008 17:01:59 GMT (envelope-from das)
Date: Sun, 29 Jun 2008 17:01:59 GMT
Message-Id: <200806291701.m5TH1xec066699@freefall.freebsd.org>
To: koie@suri.co.jp, das@FreeBSD.org, freebsd-bugs@FreeBSD.org
From: das@FreeBSD.org
Cc: 
Subject: Re: kern/68765: [mmap] a little data can be stored beyond EOF.
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jun 2008 17:01:59 -0000

Synopsis: [mmap] a little data can be stored beyond EOF.

State-Changed-From-To: open->closed
State-Changed-By: das
State-Changed-When: Sun Jun 29 16:59:31 UTC 2008
State-Changed-Why: 
This is not a bug; it is documented behavior, and other systems behave
the same way. From the first paragraph of mmap(3):

     If len is not a multiple of the page-
     size, the mapped region may extend past the specified range.  Any such
     extension beyond the end of the mapped object will be zero-filled.

The reason for this behavior is that on most architectures it isn't possible
to define a virtual memory protection boundary smaller than a page.

http://www.freebsd.org/cgi/query-pr.cgi?pr=68765