Re: LOR in VM (with backtrace)

2003-06-24 Thread Alan L. Cox
Andrew Gallatin wrote:
> 
> Alan L. Cox writes:
>  > Thanks for letting me know.  This is another false positive: Witness
>  > can't distinguish the lock on the object being destroyed from the lock
>  > on the object used by UMA because their labels are the same.  They will
>  > never, however, be the same object.  So, deadlock isn't a risk.
> 
> In a closed source driver I maintain, I had to resort to passing a
> string containing the meaningful name concatonated with some unique info
> to mtx_init().
> 
> It seems like witness could just concat the address of the mutex along
> with the strings passed to mtx_init() so as to make sure things were
> unique..
> 

I'm not sure that witness could handle the 30,000 to 200,000 distinct
mutex labels that would result from doing this for every vm object.

Regards,
Alan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: LOR in VM (with backtrace)

2003-06-24 Thread Andrew Gallatin

Alan L. Cox writes:
 > Thanks for letting me know.  This is another false positive: Witness
 > can't distinguish the lock on the object being destroyed from the lock
 > on the object used by UMA because their labels are the same.  They will
 > never, however, be the same object.  So, deadlock isn't a risk.

In a closed source driver I maintain, I had to resort to passing a
string containing the meaningful name concatonated with some unique info
to mtx_init().  

It seems like witness could just concat the address of the mutex along
with the strings passed to mtx_init() so as to make sure things were
unique..

Drew
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: LOR in VM (with backtrace)

2003-06-24 Thread Alan L. Cox
Kris Kennaway wrote:
> 
> CURRENT dated June 19;
> 
> lock order reversal
>  1st 0xc45788ac vm object (vm object) @ 
> /a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:1506
>  2nd 0xc082f110 system map (system map) @ 
> /a/asami/portbuild/i386/src-client/sys/vm/vm_kern.c:328
> 
> Debugger(c03f450d,c082f110,c043190e,c043190e,c043178f) at Debugger+0x54
> witness_lock(c082f110,8,c043178f,148,d8ca79f8) at witness_lock+0x6ac
> _mtx_lock_flags(c082f110,0,c043178f,148,c4496850) at _mtx_lock_flags+0xb1
> _vm_map_lock(c082f0b0,c043178f,148,c025dc34,246) at _vm_map_lock+0x36
> kmem_malloc(c082f0b0,1000,101,d8ca7a8c,c0390425) at kmem_malloc+0x65
> page_alloc(c083a240,1000,d8ca7a7f,101,c0457e2c) at page_alloc+0x27
> slab_zalloc(c083a240,101,c04332aa,66e,c414e5c4) at slab_zalloc+0x155
> uma_zone_slab(c083a240,101,c04332aa,66e,0) at uma_zone_slab+0xd8
> uma_zalloc_internal(c083a240,0,101,6ee,0) at uma_zalloc_internal+0x55
> uma_zfree_arg(c414e5a0,d7a86000,0,1,0) at uma_zfree_arg+0x2cc
> swp_pager_meta_free(c45788ac,1d,0,1,0) at swp_pager_meta_free+0x1b2
> swap_pager_freespace(c45788ac,1d,0,1,0) at swap_pager_freespace+0x57
> vm_object_backing_scan(c4bec5c8,4,c0432299,5f7,c0432299) at 
> vm_object_backing_scan+0x28a
> vm_object_collapse(c4bec5c8,0,c0432299,1ef,c45a0ec4) at vm_object_collapse+0x11a
> vm_object_deallocate(c4fab940,c5093ce4,c4fab940,c5093ce4,d8ca7c60) at 
> vm_object_deallocate+0x28e
> vm_map_entry_delete(c1506100,c5093ce4,c043197c,86d,c041ada4) at 
> vm_map_entry_delete+0x3b
> vm_map_delete(c1506100,0,bfc0,c1506100,c4123f00) at vm_map_delete+0x413
> vm_map_remove(c1506100,0,bfc0,11d,65) at vm_map_remove+0x55
> exit1(c4496850,0,c041a26b,65,d8ca7d40) at exit1+0x63d
> sys_exit(c4496850,d8ca7d10,c0437c26,3fd,1) at sys_exit+0x41
> syscall(2f,2f,2f,0,) at syscall+0x26e
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2829e9ff, esp = 0xbfbfde3c, ebp = 
> 0xbfbfde58 ---
> 

Thanks for letting me know.  This is another false positive: Witness
can't distinguish the lock on the object being destroyed from the lock
on the object used by UMA because their labels are the same.  They will
never, however, be the same object.  So, deadlock isn't a risk.

I will probably disable witness checking on the "system map" mutexes (or
at least the kmem_map's mutex) shortly so that folks don't become
conditioned to ignoring these.

Regards,
Alan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


LOR in VM (with backtrace)

2003-06-23 Thread Kris Kennaway
CURRENT dated June 19;

lock order reversal
 1st 0xc45788ac vm object (vm object) @ 
/a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:1506
 2nd 0xc082f110 system map (system map) @ 
/a/asami/portbuild/i386/src-client/sys/vm/vm_kern.c:328

Debugger(c03f450d,c082f110,c043190e,c043190e,c043178f) at Debugger+0x54
witness_lock(c082f110,8,c043178f,148,d8ca79f8) at witness_lock+0x6ac
_mtx_lock_flags(c082f110,0,c043178f,148,c4496850) at _mtx_lock_flags+0xb1
_vm_map_lock(c082f0b0,c043178f,148,c025dc34,246) at _vm_map_lock+0x36
kmem_malloc(c082f0b0,1000,101,d8ca7a8c,c0390425) at kmem_malloc+0x65
page_alloc(c083a240,1000,d8ca7a7f,101,c0457e2c) at page_alloc+0x27
slab_zalloc(c083a240,101,c04332aa,66e,c414e5c4) at slab_zalloc+0x155
uma_zone_slab(c083a240,101,c04332aa,66e,0) at uma_zone_slab+0xd8
uma_zalloc_internal(c083a240,0,101,6ee,0) at uma_zalloc_internal+0x55
uma_zfree_arg(c414e5a0,d7a86000,0,1,0) at uma_zfree_arg+0x2cc
swp_pager_meta_free(c45788ac,1d,0,1,0) at swp_pager_meta_free+0x1b2
swap_pager_freespace(c45788ac,1d,0,1,0) at swap_pager_freespace+0x57
vm_object_backing_scan(c4bec5c8,4,c0432299,5f7,c0432299) at 
vm_object_backing_scan+0x28a
vm_object_collapse(c4bec5c8,0,c0432299,1ef,c45a0ec4) at vm_object_collapse+0x11a
vm_object_deallocate(c4fab940,c5093ce4,c4fab940,c5093ce4,d8ca7c60) at 
vm_object_deallocate+0x28e
vm_map_entry_delete(c1506100,c5093ce4,c043197c,86d,c041ada4) at 
vm_map_entry_delete+0x3b
vm_map_delete(c1506100,0,bfc0,c1506100,c4123f00) at vm_map_delete+0x413
vm_map_remove(c1506100,0,bfc0,11d,65) at vm_map_remove+0x55
exit1(c4496850,0,c041a26b,65,d8ca7d40) at exit1+0x63d
sys_exit(c4496850,d8ca7d10,c0437c26,3fd,1) at sys_exit+0x41
syscall(2f,2f,2f,0,) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2829e9ff, esp = 0xbfbfde3c, ebp = 
0xbfbfde58 ---

[...]
#10 0xc037fef6 in _vm_map_lock (map=0x0, file=0x0, line=0)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_map.c:388
#11 0xc037efe5 in kmem_malloc (map=0xc082f0b0, size=4096, flags=257)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_kern.c:328
#12 0xc03906a7 in page_alloc (zone=0xc083a240, bytes=0, pflag=0x0, wait=0)
at /a/asami/portbuild/i386/src-client/sys/vm/uma_core.c:802
#13 0xc0390425 in slab_zalloc (zone=0xc083a240, wait=257)
at /a/asami/portbuild/i386/src-client/sys/vm/uma_core.c:711
#14 0xc03915d8 in uma_zone_slab (zone=0xc083a240, flags=257)
at /a/asami/portbuild/i386/src-client/sys/vm/uma_core.c:1493
#15 0xc0391865 in uma_zalloc_internal (zone=0xc083a240, udata=0x0, flags=257)
at /a/asami/portbuild/i386/src-client/sys/vm/uma_core.c:1648
#16 0xc0391bdc in uma_zfree_arg (zone=0x101, item=0xd7a86000, udata=0x0)
at /a/asami/portbuild/i386/src-client/sys/vm/uma_core.c:1786
#17 0xc037a292 in swp_pager_meta_free (object=0xc45788ac, index=15621429236810645533, 
count=1)
at uma.h:257
#18 0xc0378367 in swap_pager_freespace (object=0xc45788ac, start=15621429236810645533, 
size=1)
at /a/asami/portbuild/i386/src-client/sys/vm/swap_pager.c:551
#19 0xc0388b3a in vm_object_backing_scan (object=0xc4bec5c8, op=4)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:1395
#20 0xc038795a in vm_object_collapse (object=0xc4bec5c8)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:1543
#21 0xc03862de in vm_object_deallocate (object=0xc4bec5c8)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:502
#22 0xc038255b in vm_map_entry_delete (map=0xc1506100, entry=0xc5093ce4)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_map.c:2034
#23 0xc0382993 in vm_map_delete (map=0xc1506100, start=3305716964, end=3217031168)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_map.c:2166
#24 0xc0382a15 in vm_map_remove (map=0xc1506100, start=0, end=3217031168)
at /a/asami/portbuild/i386/src-client/sys/vm/vm_map.c:2188
#25 0xc0240f2d in exit1 (td=0xc4496850, rv=0) at vm_map.h:191
#26 0xc02408e1 in sys_exit () at 
/a/asami/portbuild/i386/src-client/sys/kern/kern_exit.c:102
#27 0xc03d2a8e in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1, tf_ebp = 
-1077944744, tf_isp = -657818252, tf_ebx = 674341884, tf_edx = 10, tf_ecx = 674341520, 
tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 673835519, tf_cs = 31, tf_eflags = 
642, tf_esp = -1077944772, tf_ss = 47})
at /a/asami/portbuild/i386/src-client/sys/i386/i386/trap.c:1023
#28 0xc03c2eed in Xint0x80_syscall () at {standard input}:138
-

pgp0.pgp
Description: PGP signature