Date: Sun, 12 Sep 2004 20:20:40 +0000 (UTC) From: Alan Cox <alc@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c Message-ID: <200409122020.i8CKKe6Q043155@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
alc 2004-09-12 20:20:40 UTC
FreeBSD src repository
Modified files:
sys/amd64/amd64 pmap.c
sys/i386/i386 pmap.c
Log:
Use an atomic op to update the pte in pmap_protect(). This is to prevent
the loss of a page modified (PG_M) bit in a race between processors.
Quoting Tor:
One scenario where the old code could cause a lost PG_M bit is a
multithreaded linux program (or FreeBSD program using the
linuxthreads port) where one thread was starting a subprocess.
The thread doing fork() would call vmspace_fork(), which would then
call vm_map_copy_entry() which would call pmap_protect() on an area
possibly accessed by other threads.
Additionally, make the clearing of PG_M by pmap_protect() unconditional if
write permission is removed. Previously, PG_M could persist on a read-only
unmanaged page. That seems inconsistent and confusing.
In collaboration with: tegge@
MT5 candidate
PR: 61852
Revision Changes Path
1.498 +7 -6 src/sys/amd64/amd64/pmap.c
1.504 +13 -7 src/sys/i386/i386/pmap.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409122020.i8CKKe6Q043155>