Recent runs of the babylon5 ATF tests are causing kernel panics in the malloc_clip test case of the lib/libc/sys/t_mlock test.
[ 6588.6440439] pmap_unwire: wiring for pmap 0xc23abd70 va 0xaf7a7000did not change! [ 6588.6679535] panic: kernel diagnostic assertion "pg->wire_count > 0" failed: file "/tmp/bracket/build/2019.03.11.09.20.14-i386/src/sys/uvm/uvm_page.c", line 1594 [ 6588.6679535] cpu0: Begin traceback... [ 6588.6679535] vpanic(c107f740,c9218d30,c9218d44,c08e20be,c107f740,c107f67f,c1131435,c113414c,63a,c9218de4) at netbsd:vpanic+0x12d [ 6588.6848068] kern_assert(c107f740,c107f67f,c1131435,c113414c,63a,c9218de4,c9218d80,c08cfa04,c16f72e4,af7a7000) at netbsd:kern_assert+0x23 [ 6588.7048431] uvm_pagewire(c16f72e4,af7a7000,2027000,3,33,3,af7a7000,0,c23abd70,c9218e01) at netbsd:uvm_pagewire+0x80 [ 6588.7248380] uvm_fault_upper_enter.isra.5(c2487de0,c16f72e4,c2487de0,1,c08e52f5,c16f72e4,c9218e40,4a856370,c9218e28,c9218e28) at netbsd:uvm_fault_upper_enter.isra.5+0x1dd [ 6588.7248380] uvm_fault_internal(c23770dc,af7a7000,3,3,c23770ec,c23a9f28,c237710c,af7a8000,c9218f0c,c08d89a6) at netbsd:uvm_fault_internal+0x1500 [ 6588.7450318] uvm_fault_wire(c23770dc,af7a7000,af7a8000,3,1,0,59,c237710c,c23a9f28,1000) at netbsd:uvm_fault_wire+0x4f [ 6589.1842794] uvm_map_pageable(c23770dc,af7a7000,af7a8000,0,0,af7a8000,c21a8c60,c9218fa8,c138899c,c9218f9c) at netbsd:uvm_map_pageable+0x1bc [ 6589.1969712] sys_mlock(c21a8c60,c9218f68,c9218f60,c1c19004,c9216000,c9218f60,cb,c9218f68,0,0) at netbsd:sys_mlock+0xb9 [ 6589.2170905] syscall() at netbsd:syscall+0x143 [ 6589.2170905] --- syscall (number 203) --- [ 6589.2370658] af7f3297: [ 6589.2370658] cpu0: End traceback... This looks to have started happening after the following commits commit 2019.03.10.14.45.53 kre src/sys/kern/kern_time.c 1.197 commit 2019.03.10.15.18.45 kre src/bin/sleep/sleep.c 1.30 commit 2019.03.10.15.31.02 christos src/include/malloc.h 1.7 commit 2019.03.10.15.32.42 christos src/external/bsd/jemalloc/lib/Makefile.inc 1.5 commit 2019.03.10.15.45.26 christos src/external/bsd/jemalloc/include/jemalloc/jemalloc.h 1.4 commit 2019.03.10.15.45.26 christos src/external/bsd/jemalloc/include/jemalloc/jemalloc_defs.h 1.2 Of which the only kernel changes are mine - but I cannot imagine how those can possibly affect anything related to the pmap. Christos' changes should have only affected userland, so unless those uncovered a latent bug that has been there previously (which is not impossible, I presume that jemalloc() might be using mmap() to allocate/free its arena, and perhaps mlock() as well) I have no idea what the cause of this might be. kre
