> #11 0xffffffff80976e12 in vmem_xfree (vm=0xffffffff816d2200, > addr=18446741889258000384, size=0) at /usr/src/sys/kern/subr_vmem.c:1237 > #12 0xffffffff80bafbe0 in memguard_free (ptr=<value optimized out>) at > /usr/src/sys/vm/memguard.c:421 > #13 0xffffffff80904191 in free (addr=0xfffffe03648a9000, mtp=<value optimized > out>) at /usr/src/sys/kern/kern_malloc.c:554 > #14 0xffffffff808e733f in proc_reap (td=<value optimized out>, > p=0xfffff80bf043c000, status=<value optimized out>, options=<value optimized > out>) at /usr/src/sys/kern/kern_exit.c:882 > #15 0xffffffff808e784a in proc_to_reap (td=0xfffff8021d499000, > p=0xfffff80bf043c000, idtype=<value optimized out>, id=<value optimized out>, > status=0xfffffe35559bc914, options=55,
The assert is "size > 0". I enabled vm.memguard.options=3 while the system was running. From reading is_memguard_addr() I assume it should be safe to do so. Only new allocations should be passed through memguard_free(). This panic seems to happen easily. This comment in sys/vm/memguard.c memguard_free() makes me think something is stale: > /* > * This requires carnal knowledge of the implementation of > * kmem_free(), but since we've already replaced kmem_malloc() > * above, it's not really any worse. We want to use the > * vm_map lock to serialize updates to memguard_wasted, since > * we had the lock at increment. > */ > kmem_unback(kmem_object, addr, size); > if (sizev > size) > addr -= PAGE_SIZE; > vmem_xfree(memguard_arena, addr, sizev); By the way, I can't get the kernel to even boot with vm.memguard.options=3. It panics very early in device probing IIRC. -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature
