From owner-cvs-all@FreeBSD.ORG  Sun Sep 12 20:20:40 2004
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id E276E16A4CE; Sun, 12 Sep 2004 20:20:40 +0000 (GMT)
Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id DBCD943D45; Sun, 12 Sep 2004 20:20:40 +0000 (GMT)
	(envelope-from alc@FreeBSD.org)
Received: from repoman.freebsd.org (localhost [127.0.0.1])
	by repoman.freebsd.org (8.12.11/8.12.11) with ESMTP id i8CKKeSr043156;
	Sun, 12 Sep 2004 20:20:40 GMT
	(envelope-from alc@repoman.freebsd.org)
Received: (from alc@localhost)
	by repoman.freebsd.org (8.12.11/8.12.11/Submit) id i8CKKe6Q043155;
	Sun, 12 Sep 2004 20:20:40 GMT
	(envelope-from alc)
Message-Id: <200409122020.i8CKKe6Q043155@repoman.freebsd.org>
From: Alan Cox <alc@FreeBSD.org>
Date: Sun, 12 Sep 2004 20:20:40 +0000 (UTC)
To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org,
	cvs-all@FreeBSD.org
X-FreeBSD-CVS-Branch: HEAD
Subject: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Sep 2004 20:20:41 -0000

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