The fix below fixes the following panic that mglocker@ was seeing on
macppc:
panic: uvm_addr_invoke: address selector 0xfe8000 (uaddr_bestfit
0xe0000000-0xee000000) returned unavailable address 0xe8a59000
This happened immediately after a failed malloc(9). What is happening
here is that we end up calling uvm_map_kmem_grow() on kmem_map, which
is a submap of kernel_map. The end of kmem_map is smaller than
uvm_maxkaddr. So we end up setting uvm_maxkaddr to a smaller value.
The next allocation out of kernel_map that returns an adress larger
than uvm_maxkaddr will now trigger the panic.
We should never reduce uvm_maxkaddr. The diff below makes sure that
we don't.
This will probably fix similar panics that we have seen on sparc.
ok?
P.S. I think this function is somewhat retarded when dealing with
submaps of kernel_map and/or architectures without pmap_growkernel().
But let's fix this long-standing bug first before we try to address
that issue.
Index: uvm_map.c
===================================================================
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.213
diff -u -p -r1.213 uvm_map.c
--- uvm_map.c 8 May 2016 16:29:57 -0000 1.213
+++ uvm_map.c 2 Jun 2016 20:18:11 -0000
@@ -4573,7 +4573,7 @@ uvm_map_kmem_grow(struct vm_map *map, st
#ifdef PMAP_GROWKERNEL
uvm_maxkaddr = pmap_growkernel(end);
#else
- uvm_maxkaddr = end;
+ uvm_maxkaddr = MAX(uvm_maxkaddr, end);
#endif
/* Rebuild free list. */
