From owner-freebsd-hackers@FreeBSD.ORG  Fri Aug  8 01:01:24 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8EF4437B401
	for <hackers@FreeBSD.ORG>; Fri,  8 Aug 2003 01:01:24 -0700 (PDT)
Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net
	[66.199.86.114])
	by mx1.FreeBSD.org (Postfix) with ESMTP id EB7A743FA3
	for <hackers@FreeBSD.ORG>; Fri,  8 Aug 2003 01:01:23 -0700 (PDT)
	(envelope-from das@FreeBSD.ORG)
Received: from HAL9000.homeunix.com (localhost [127.0.0.1])
	by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h78817jX016153;
	Fri, 8 Aug 2003 01:01:07 -0700 (PDT)
	(envelope-from das@FreeBSD.ORG)
Received: (from das@localhost)
	by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h78816Id016152;
	Fri, 8 Aug 2003 01:01:06 -0700 (PDT)
	(envelope-from das@FreeBSD.ORG)
Date: Fri, 8 Aug 2003 01:01:06 -0700
From: David Schultz <das@FreeBSD.ORG>
To: Ed L Cashin <ecashin@uga.edu>
Message-ID: <20030808080106.GC15882@HAL9000.homeunix.com>
Mail-Followup-To: Ed L Cashin <ecashin@uga.edu>,
	Luoqi Chen <lchen@briontech.com>, hackers@FreeBSD.org
References: <AHEKICEOIHLOGINAFIINIEDICBAA.lchen@briontech.com>
	<87smodwlq1.fsf@uga.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87smodwlq1.fsf@uga.edu>
cc: hackers@FreeBSD.ORG
cc: Luoqi Chen <lchen@briontech.com>
Subject: Re: COW and mprotect on non-shared memory
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2003 08:01:24 -0000

On Thu, Aug 07, 2003, Ed L Cashin wrote:
> "Luoqi Chen" <lchen@briontech.com> writes:
> 
> [Ed writes]
> >> That means that if I do this:
> >> 
> >>     for (i = 0; i < n; ++i) {
> >>       assert(!mprotect(p, pgsiz, PROT_NONE));
> >>       assert(!mprotect(p, pgsiz, PROT_READ|PROT_WRITE|PROT_EXEC));
> >>       p[i] = i & 0xff;
> >>     }
> >> 
> >> ... I get n minor page faults!  Pretty amazing, but I guess they
> >> figured nobody does that.  
> 
> ...
> > The first mprotect() removes the physical mapping from the page
> > table, the second mprotect() doesn't do anything because the mapping
> > isn't there. So when the page is accessed, a fault is needed to
> > insert the mapping back to the page table.
> 
> OK, thanks.  I can see that in sys/i386/i386/pmap.c.  It leaves me
> wondering what MAP_ENTRY_COW is for, though.

It's an optimization that makes the map entries and corresponding
vm_objects themselves copy-on-write.  Specifically, when a process
forks, FreeBSD does not allocate new shadow objects immediately.
This is deferred until the object needs to be modified, which is
usually never if the process subsequently calls exec.