On Sun, Oct 19, 2003 at 11:21:47AM +0200, Paolo Pisati wrote: > > ...lock order reversal > 1st 0xc3142a68 vm object (vm object) _at_ /usr/src/sys/vm/vm_object.c:433 > 2nd 0xc102f110 system map (system map) _at_ /usr/src/sys/vm/vm_kern.c:328 Harmless. From alc: ---- In general, any LOR involving a system map mutex and a vm object mutex that has a stack trace looking like _mtx_lock_flags() _vm_map_lock() kmem_malloc() page_alloc() slab_zalloc() uma_zone_slab() uma_zalloc_internal() uma_zfree_arg() ... is not a problem. ---- > Stack backtrace: > _mtx_lock_flags(c102f110,0,c0850fb1,148,3) at _mtx_lock_flags+0xba > _vm_map_lock(c102f0b0,c0850fb1,148,c08feb80,2b4) at _vm_map_lock+0x36 > kmem_malloc(c102f0b0,1000,101,d2762aa8,c079a707) at kmem_malloc+0x3a > page_alloc(c103a3c0,1000,d2762a9b,101,c083ab1b) at page_alloc+0x27 > slab_zalloc(c103a3c0,1,8,c08528ff,68c) at slab_zalloc+0xb7 > uma_zone_slab(c103a3c0,1,c08528ff,68c,0) at uma_zone_slab+0xe6 > uma_zalloc_internal(c103a3c0,0,1,0,c101f470) at uma_zalloc_internal+0x3e > bucket_alloc(80,1,c08528ff,70b,0) at bucket_alloc+0x5e > uma_zfree_arg(c101f3c0,d278be04,0,778,60) at uma_zfree_arg+0x2c6 Kris
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:25 UTC