> #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.

Bryan Drewery

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to