Date: Wed, 6 Aug 2003 13:45:37 -0700 From: "Luoqi Chen" <lchen@briontech.com> To: "Ed L Cashin" <ecashin@uga.edu>, <hackers@freebsd.org> Subject: RE: COW and mprotect on non-shared memory Message-ID: <AHEKICEOIHLOGINAFIINIEDICBAA.lchen@briontech.com> In-Reply-To: <87he4uzr1z.fsf@uga.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> For that reason, when you mprotect an area of non-shared, anonymous > memory to no access and then back to writable, Linux has no way of > knowing that the memory wasn't set for COW before you make it > unwritable. It goes ahead and makes all the pages in the area COW. > > 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. > > More surprising is that the same test program has the same behavior on > FreeBSD. (At least, the "/usr/bin/time -l ..." output shows the > number of page reclaims increasing at the same rate that I increase > the value of n in the loop.) > > I thought that in FreeBSD any COW area would have its own vm_map_entry > with the MAP_ENTRY_COW bit set. That way, you could run this test > without any minor faults at all. Now I suspect I was incorrect. > Could anyone help clarify the situation for me? > > Thanks. > > -- > --Ed L Cashin | PGP public key: > ecashin@uga.edu | http://noserose.net/e/pgp/ > 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. -lq
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AHEKICEOIHLOGINAFIINIEDICBAA.lchen>