vm/map LOR

[Alan L. Cox]

Bosko Milekic wrote:
> 
>  fakepg_zone should probably be UMA_ZONE_VM.  Or the vm_object lock
>  needs to be dropped before allocating or freeing to that zone.
> 
>  What does Alan think? (cc'd)
> 

Perhaps.  Regardless, in this case, the lock-order reversal is a false
positive.  What it shows is the locking of a user-level vm map, followed
by vm_object #1, followed by the kmem_map.  If this had proceeded to
conclusion, you would have seen the locking of vm_object #2, the
kmem_object.  So, to witness this appears as a lock-order reversal. 
Unless vm_object #1 and vm_object #2 are the same, there is no
possibility of deadlock.  Witness is simply unable to distinguish the
two vm objects because they have the same label.  If they were given
unique labels, witness would be overwhelmed because there are simply too
many vm objects.

Regards,
Alan

> 
> On Thu, Jul 31, 2003 at 04:46:06PM -0700, Lars Eggert wrote:
> > Hi,
> >
> > with yesterday's -current:
> >
> >  1st 0xc6dfd094 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:434
> >  2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:323
> >
> > Stack backtrace:
> > backtrace(c032000b,c082f110,c033362f,c033362f,c03334c6) at backtrace+0x17
> > witness_lock(c082f110,8,c03334c6,143,c082f0b0) at witness_lock+0x686
> > _mtx_lock_flags(c082f110,0,c03334c6,143,101) at _mtx_lock_flags+0xb5
> > _vm_map_lock(c082f0b0,c03334c6,143,c0374778,c03747a0) at _vm_map_lock+0x36
> > kmem_malloc(c082f0b0,1000,101,eb44db14,c02b0433) at kmem_malloc+0x3a
> > page_alloc(c083a240,1000,eb44db07,101,0) at page_alloc+0x27
> > slab_zalloc(c083a240,101,c083a254,8,c0334e1e) at slab_zalloc+0xc2
> > uma_zone_slab(c083a240,101,c0334e1e,663,165) at uma_zone_slab+0xd9
> > uma_zalloc_internal(c083a240,0,101,6e7,0) at uma_zalloc_internal+0x4f
> > uma_zfree_arg(c083a900,c6e31000,0,eb44dbc4,c029884d) at uma_zfree_arg+0x2a6
> > dev_pager_putfake(c6e31000,0,c0332b9e,be,c6dfd094) at dev_pager_putfake+0x35
> > dev_pager_dealloc(c6dfd094,1,c0334dcf,10c,0) at dev_pager_dealloc+0xb9
> > vm_pager_deallocate(c6dfd094,0,c0333f6c,261,1b2) at vm_pager_deallocate+0x3d
> > vm_object_terminate(c6dfd094,0,c0333f6c,1b2,c6b894ec) at
> > vm_object_terminate+0x1e5
> > vm_object_deallocate(c6dfd094,c082bd20,c6dfd094,c082bd20,eb44dca0) at
> > vm_object_deallocate+0x35e
> > vm_map_entry_delete(c6593e00,c082bd20,c033369d,897,c019f843) at
> > vm_map_entry_delete+0x3c
> > vm_map_delete(c6593e00,282e2000,282e3000,1000,282e2000) at
> > vm_map_delete+0x3c3
> > vm_map_remove(c6593e00,282e2000,282e3000,0,c6b8a618) at vm_map_remove+0x55
> > munmap(c6ae24c0,eb44dd14,c0339293,3ee,2) at munmap+0x9e
> > syscall(2f,2f,2f,f8000,1000) at syscall+0x260
> > Xint0x80_syscall() at Xint0x80_syscall+0x1d
> > --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 ---
> >
> > Lars
> > --
> > Lars Eggert <larse at isi.edu>           USC Information Sciences Institute
> 
> --
> Bosko Milekic  *  bmilekic at technokratis.com  *  bmilekic at FreeBSD.org
> TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/