About pmap_mapdev() & pmap_unmapdev()

From: Kohji Okuno <okuno.kohji_at_jp.panasonic.com>
Date: Fri, 03 Oct 2014 17:25:33 +0900 (JST)
Hi,

At least in i386 && 9-stable, when we call pmap_mapdev() and
pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
incorrectly.

pmap_mapdev_attr()->pmap_kenter_attr():
In this path, kernel_pmap.pm_stats.resident_count is not increlmented.

pmap_unmapdev()->kmem_free(kernel_map)->vm_map_remove()->pmap_remove():
But, in this path, kernel_pmap.pm_stats.resident_count is decreased in
pmap_remove_pte().

While I called pmap_mapdev() and pmap_unmapdev() repeatedly and
kernel_pmap.pm_stats.resident_count became `0', since pmap_remove()
returned without removing ptes, I encountered various kernel panics.

And, when I enabled INVARIANTS, I looked the following panic message.
panic: vm_page_free_toq: freeing mapped page 0xXXXXXXXX.

I think, I should change the following.
What do you think about this?


diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c
index 2adc6f8..a0998e8 100644
--- a/sys/i386/i386/pmap.c
+++ b/sys/i386/i386/pmap.c
_at__at_ -5061,6 +5061,7 _at__at_ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode)
 {
 	vm_offset_t va, offset;
 	vm_size_t tmpsize;
+	int kmem_allocated = 0;
 
 	offset = pa & PAGE_MASK;
 	size = roundup(offset + size, PAGE_SIZE);
_at__at_ -5068,13 +5069,18 _at__at_ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode)
 
 	if (pa < KERNLOAD && pa + size <= KERNLOAD)
 		va = KERNBASE + pa;
-	else
+	else {
 		va = kmem_alloc_nofault(kernel_map, size);
+		kmem_allocated = 1;
+	}
 	if (!va)
 		panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
 
-	for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE)
+	for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) {
 		pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
+		if (kmem_allocated)
+			kernel_pmap.pm_stats.resident_count++;
+	}
 	pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
 	pmap_invalidate_cache_range(va, va + size);
 	return ((void *)(va + offset));
Received on Fri Oct 03 2014 - 06:25:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:52 UTC