Module Name: src
Committed By: maxv
Date: Fri Aug 19 18:24:57 UTC 2016
Modified Files:
src/sys/arch/x86/x86: pmap.c
Log Message:
Switch the XXXCDC to panics. Normally it should never be triggered, since
the kernel space is above the PTE space, and the user space is below it.
Any attempt to write or remove this area should be blocked by UVM earlier.
To generate a diff of this commit:
cvs rdiff -u -r1.219 -r1.220 src/sys/arch/x86/x86/pmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/arch/x86/x86/pmap.c
diff -u src/sys/arch/x86/x86/pmap.c:1.219 src/sys/arch/x86/x86/pmap.c:1.220
--- src/sys/arch/x86/x86/pmap.c:1.219 Fri Aug 19 18:04:39 2016
+++ src/sys/arch/x86/x86/pmap.c Fri Aug 19 18:24:57 2016
@@ -1,4 +1,4 @@
-/* $NetBSD: pmap.c,v 1.219 2016/08/19 18:04:39 maxv Exp $ */
+/* $NetBSD: pmap.c,v 1.220 2016/08/19 18:24:57 maxv Exp $ */
/*-
* Copyright (c) 2008, 2010, 2016 The NetBSD Foundation, Inc.
@@ -171,7 +171,7 @@
*/
#include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.219 2016/08/19 18:04:39 maxv Exp $");
+__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.220 2016/08/19 18:24:57 maxv Exp $");
#include "opt_user_ldt.h"
#include "opt_lockdebug.h"
@@ -3400,23 +3400,17 @@ pmap_remove(struct pmap *pmap, vaddr_t s
blkendva = eva;
/*
- * XXXCDC: our PTE mappings should never be removed
- * with pmap_remove! if we allow this (and why would
- * we?) then we end up freeing the pmap's page
- * directory page (PDP) before we are finished using
- * it when we hit in in the recursive mapping. this
- * is BAD.
+ * Our PTE mappings should never be removed with pmap_remove.
*
- * long term solution is to move the PTEs out of user
- * address space. and into kernel address space (up
- * with APTE). then we can set VM_MAXUSER_ADDRESS to
- * be VM_MAX_ADDRESS.
+ * XXXmaxv: still needed?
+ *
+ * A long term solution is to move the PTEs out of user address
+ * space, and into kernel address space. Then we can set
+ * VM_MAXUSER_ADDRESS to be VM_MAX_ADDRESS.
*/
-
- /* XXXCDC: ugly hack to avoid freeing PDP here */
for (i = 0; i < PDP_SIZE; i++) {
if (pl_i(va, PTP_LEVELS) == PDIR_SLOT_PTE+i)
- continue;
+ panic("PTE space accessed");
}
lvl = pmap_pdes_invalid(va, pdes, &pde);
@@ -3862,18 +3856,17 @@ pmap_write_protect(struct pmap *pmap, va
blockend = eva;
/*
- * XXXCDC: our PTE mappings should never be write-protected!
+ * Our PTE mappings should never be write-protected.
*
- * long term solution is to move the PTEs out of user
- * address space. and into kernel address space (up
- * with APTE). then we can set VM_MAXUSER_ADDRESS to
- * be VM_MAX_ADDRESS.
+ * XXXmaxv: still needed?
+ *
+ * A long term solution is to move the PTEs out of user address
+ * space, and into kernel address space. Then we can set
+ * VM_MAXUSER_ADDRESS to be VM_MAX_ADDRESS.
*/
- /* XXXCDC: ugly hack to avoid freeing PDP here */
- /* XXX: this loop makes no sense at all */
for (i = 0; i < PDP_SIZE; i++) {
if (pl_i(va, PTP_LEVELS) == PDIR_SLOT_PTE+i)
- continue;
+ panic("PTE space accessed");
}
/* Is it a valid block? */
@@ -4012,7 +4005,7 @@ pmap_enter_ma(struct pmap *pmap, vaddr_t
if (va < VM_MAXUSER_ADDRESS)
npte |= PG_u;
else if (va < VM_MAX_ADDRESS)
- npte |= (PG_u | PG_RW); /* XXXCDC: no longer needed? */
+ panic("PTE space accessed"); /* XXXmaxv: no longer needed? */
else
npte |= PG_k;
if (pmap == pmap_kernel())
