Date: Fri, 8 Aug 2003 01:01:06 -0700 From: David Schultz <das@FreeBSD.ORG> To: Ed L Cashin <ecashin@uga.edu> Cc: Luoqi Chen <lchen@briontech.com> Subject: Re: COW and mprotect on non-shared memory Message-ID: <20030808080106.GC15882@HAL9000.homeunix.com> In-Reply-To: <87smodwlq1.fsf@uga.edu> References: <AHEKICEOIHLOGINAFIINIEDICBAA.lchen@briontech.com> <87smodwlq1.fsf@uga.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030808080106.GC15882>