From owner-cvs-all@FreeBSD.ORG Thu Jul 20 17:48:42 2006 Return-Path: X-Original-To: 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 0061316A4E1; Thu, 20 Jul 2006 17:48:41 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD65B43D46; Thu, 20 Jul 2006 17:48:41 +0000 (GMT) (envelope-from alc@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id k6KHmf0u030245; Thu, 20 Jul 2006 17:48:41 GMT (envelope-from alc@repoman.freebsd.org) Received: (from alc@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id k6KHmf7s030244; Thu, 20 Jul 2006 17:48:41 GMT (envelope-from alc) Message-Id: <200607201748.k6KHmf7s030244@repoman.freebsd.org> From: Alan Cox Date: Thu, 20 Jul 2006 17:48:41 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c src/sys/sparc64/include pmap.h src/sys/vm pmap.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 17:48:42 -0000 alc 2006-07-20 17:48:41 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386 pmap.c sys/sparc64/include pmap.h sys/vm pmap.h Log: Add pmap_clear_write() to the interface between the virtual memory system's machine-dependent and machine-independent layers. Once pmap_clear_write() is implemented on all of our supported architectures, I intend to replace all calls to pmap_page_protect() by calls to pmap_clear_write(). Why? Both the use and implementation of pmap_page_protect() in our virtual memory system has subtle errors, specifically, the management of execute permission is broken on some architectures. The "prot" argument to pmap_page_protect() should behave differently from the "prot" argument to other pmap functions. Instead of meaning, "give the specified access rights to all of the physical page's mappings," it means "don't take away the specified access rights from all of the physical page's mappings, but do take away the ones that aren't specified." However, owing to our i386 legacy, i.e., no support for no-execute rights, all but one invocation of pmap_page_protect() specifies VM_PROT_READ only, when the intent is, in fact, to remove only write permission. Consequently, a faithful implementation of pmap_page_protect(), e.g., ia64, would remove execute permission as well as write permission. On the other hand, some architectures that support execute permission have basically ignored whether or not VM_PROT_EXECUTE is passed to pmap_page_protect(), e.g., amd64 and sparc64. This change represents the first step in replacing pmap_page_protect() by the less subtle pmap_clear_write() that is already implemented on amd64, i386, and sparc64. Discussed with: grehan@ and marcel@ Revision Changes Path 1.567 +1 -2 src/sys/amd64/amd64/pmap.c 1.571 +1 -2 src/sys/i386/i386/pmap.c 1.47 +0 -2 src/sys/sparc64/include/pmap.h 1.78 +1 -0 src/sys/vm/pmap.h