panic: mutex vm object not owned ...

[Peter Grehan]

Coleman Kane wrote:

 > panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:608
 >0xd7cc1ac8: at panic+0x134
 >0xd7cc1b68: at _mtx_assert+0x74
 >0xd7cc1b88: at vm_page_remove+0x5c
 >0xd7cc1ba8: at vm_page_free_toq+0xcc
 >0xd7cc1bc8: at vm_page_free+0x28
 >0xd7cc1be8: at uma_small_free+0x60
 >0xd7cc1c18: at zone_drain+0x2e8
 >0xd7cc1c58: at zone_foreach+0x64
 >0xd7cc1c78: at uma_reclaim+0x20
 >0xd7cc1c98: at vm_pageout_scan+0x200
 >0xd7cc1d58: at vm_pageout+0x39c
 >0xd7cc1d98: at fork_exit+0x118
 >0xd7cc1dc8: at fork_trampoline+0xc
  ...
> Yeah, I've been seeing this as well (on my AMD64 machine) lately. Any
> idea where it is from?

  Yes - it's rev 1.114 of uma_core.c. The comment "as the page(s) 
undoubtedly came from kmem_map for those two." isn't true for the
UMD_MD_SMALL_ALLOC case.

  It was assumed pre-1.114 that non-UMA_SLAB_KMEM were allocated with 
NULL backing objects, which can be seen from amd64/amd64/uma_machdep.c:

void *
uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait)
{
    ...
         *flags = UMA_SLAB_PRIV;

    ...
                  m = vm_page_alloc(NULL, colour++, pflags | 
VM_ALLOC_NOOBJ);
    ...


  Try backing out the couple of lines from that rev and see how it goes.

later,

Peter.