memguard(9) panics in proc_reap with vm.memguard.options=3

[Bryan Drewery]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140924/fe5ae80a/attachment.sig>