Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/sys/arch/x86/x86 Switch the XXXCDC to panics. Normally it sh...
details: https://anonhg.NetBSD.org/src/rev/b72957a39e4d
branches: trunk
changeset: 817403:b72957a39e4d
user: maxv <maxv%NetBSD.org@localhost>
date: Fri Aug 19 18:24:57 2016 +0000
description:
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.
diffstat:
sys/arch/x86/x86/pmap.c | 41 +++++++++++++++++------------------------
1 files changed, 17 insertions(+), 24 deletions(-)
diffs (84 lines):
diff -r 859bf9a7b87e -r b72957a39e4d sys/arch/x86/x86/pmap.c
--- a/sys/arch/x86/x86/pmap.c Fri Aug 19 18:08:50 2016 +0000
+++ b/sys/arch/x86/x86/pmap.c Fri Aug 19 18:24:57 2016 +0000
@@ -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 @@
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.
+ *
+ * XXXmaxv: still needed?
*
- * 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.
+ * 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 @@
blockend = eva;
/*
- * XXXCDC: our PTE mappings should never be write-protected!
+ * Our PTE mappings should never be write-protected.
+ *
+ * XXXmaxv: still needed?
*
- * 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.
+ * 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 @@
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())
Home |
Main Index |
Thread Index |
Old Index