uvm_km_pgremove_intrsafe(): properly compute the size to pmap_kremove()

(do not trucate it to the first __PGRM_BATCH pages per batch): if we were
given a sparse mapping, we could leave mappings in place.
Note that this doesn't seem to be a problem right now: I added a KASSERT
in my private tree to see if uvm_km_pgremove_intrsafe() would use a
too short size, and it didn't fire.
This commit is contained in:
bouyer 2012-03-12 21:37:12 +00:00
parent 77bfe129a9
commit 1cc4347583
1 changed files with 3 additions and 3 deletions

View File

@ -1,4 +1,4 @@
/* $NetBSD: uvm_km.c,v 1.123 2012/02/25 22:28:06 rmind Exp $ */
/* $NetBSD: uvm_km.c,v 1.124 2012/03/12 21:37:12 bouyer Exp $ */
/*
* Copyright (c) 1997 Charles D. Cranor and Washington University.
@ -120,7 +120,7 @@
*/
#include <sys/cdefs.h>
__KERNEL_RCSID(0, "$NetBSD: uvm_km.c,v 1.123 2012/02/25 22:28:06 rmind Exp $");
__KERNEL_RCSID(0, "$NetBSD: uvm_km.c,v 1.124 2012/03/12 21:37:12 bouyer Exp $");
#include "opt_uvmhist.h"
@ -485,7 +485,7 @@ uvm_km_pgremove_intrsafe(struct vm_map *map, vaddr_t start, vaddr_t end)
}
npgrm = i;
/* now remove the mappings */
pmap_kremove(batch_vastart, PAGE_SIZE * npgrm);
pmap_kremove(batch_vastart, va - batch_vastart);
/* and free the pages */
for (i = 0; i < npgrm; i++) {
pg = PHYS_TO_VM_PAGE(pa[i]);