lock order reversal bufwait/dirhash
Got this during installworld (source on NFS, destination UFS on CF-card) Source is current checked out yesterday. lock order reversal: 1st 0xc28b85b4 bufwait (bufwait) @ /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575 2nd 0xc343f000 dirhash (dirhash) @ /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283 KDB: stack backtrace: db_trace_self_wrapper(c0905b2b,c0d02c56,c2d3d030,c2d40500,ca657890,...) at db_trace_self_wrapper+0x26 _witness_debugger(c0d02c56,c343f000,c0d279c2,c2d40500,c0d2762e,...) at _witness_debugger+0x25 witness_checkorder(c343f000,9,c0d2762e,11b,0,...) at witness_checkorder+0x73c _sx_xlock(c343f000,0,c0d2762e,11b,c3a07e80,...) at _sx_xlock+0x51 ufsdirhash_acquire(e,1828,ca6579f0,c3a07e80,cb2bd814,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c3a07e80,ca6579f0,1828,ca657950,ca657954,...) at ufsdirhash_add+0x1f ufs_direnter(c3944dd0,c423e220,ca6579f0,ca657bd0,c292ccb0,...) at ufs_direnter+0x894 ufs_mkdir(ca657bf8,ca657c0c,2,0,0,...) at ufs_mkdir+0x51c VOP_MKDIR_APV(c0e0f4c0,ca657bf8,ca657bd0,ca657b3c,2,...) at VOP_MKDIR_APV+0x8e kern_mkdirat(c39264e0,ff9c,80513e0,0,1c0,...) at kern_mkdirat+0x240 kern_mkdir(c39264e0,80513e0,0,1c0,ca657c7c,...) at kern_mkdir+0x2f mkdir(c39264e0,ca657cec,ca657d28,c0d014f7,0,...) at mkdir+0x27 syscallenter(c39264e0,ca657ce4,ca657ce4,0,c0e630c0,...) at syscallenter+0xc6 syscall(ca657d28) at syscall+0x3a Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x281817cf, esp = 0xbfbfe30c, ebp = 0xbfbfe398 --- -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: lock order reversal bufwait/dirhash
On Jun 9, 2010, at 12:51 AM, Bernd Walter wrote: Got this during installworld (source on NFS, destination UFS on CF-card) Source is current checked out yesterday. lock order reversal: 1st 0xc28b85b4 bufwait (bufwait) @ /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575 2nd 0xc343f000 dirhash (dirhash) @ /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283 KDB: stack backtrace: db_trace_self_wrapper(c0905b2b,c0d02c56,c2d3d030,c2d40500,ca657890,...) at db_trace_self_wrapper+0x26 _witness_debugger(c0d02c56,c343f000,c0d279c2,c2d40500,c0d2762e,...) at _witness_debugger+0x25 witness_checkorder(c343f000,9,c0d2762e,11b,0,...) at witness_checkorder+0x73c _sx_xlock(c343f000,0,c0d2762e,11b,c3a07e80,...) at _sx_xlock+0x51 ufsdirhash_acquire(e,1828,ca6579f0,c3a07e80,cb2bd814,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c3a07e80,ca6579f0,1828,ca657950,ca657954,...) at ufsdirhash_add+0x1f ufs_direnter(c3944dd0,c423e220,ca6579f0,ca657bd0,c292ccb0,...) at ufs_direnter+0x894 ufs_mkdir(ca657bf8,ca657c0c,2,0,0,...) at ufs_mkdir+0x51c VOP_MKDIR_APV(c0e0f4c0,ca657bf8,ca657bd0,ca657b3c,2,...) at VOP_MKDIR_APV+0x8e kern_mkdirat(c39264e0,ff9c,80513e0,0,1c0,...) at kern_mkdirat+0x240 kern_mkdir(c39264e0,80513e0,0,1c0,ca657c7c,...) at kern_mkdir+0x2f mkdir(c39264e0,ca657cec,ca657d28,c0d014f7,0,...) at mkdir+0x27 syscallenter(c39264e0,ca657ce4,ca657ce4,0,c0e630c0,...) at syscallenter+0xc6 syscall(ca657d28) at syscall+0x3a Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x281817cf, esp = 0xbfbfe30c, ebp = 0xbfbfe398 --- I've seen this for a while, but it was definitely present on the kernel that I tried working off of that was from Saturday. Thanks, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: lock order reversal bufwait/dirhash
On Wednesday 09 June 2010 3:51:52 am Bernd Walter wrote: Got this during installworld (source on NFS, destination UFS on CF-card) Source is current checked out yesterday. lock order reversal: 1st 0xc28b85b4 bufwait (bufwait) @ /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575 2nd 0xc343f000 dirhash (dirhash) @ /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283 KDB: stack backtrace: Known false positive. From ufs_dirhash.c: /* * Locking: * * The relationship between inode and dirhash is protected either by an * exclusive vnode lock or the vnode interlock where a shared vnode lock * may be used. The dirhash_mtx is acquired after the dirhash lock. To * handle teardown races, code wishing to lock the dirhash for an inode * when using a shared vnode lock must obtain a private reference on the * dirhash while holding the vnode interlock. They can drop it once they * have obtained the dirhash lock and verified that the dirhash wasn't * recycled while they waited for the dirhash lock. * * ufsdirhash_build() acquires a shared lock on the dirhash when it is * successful. This lock is released after a call to ufsdirhash_lookup(). * * Functions requiring exclusive access use ufsdirhash_acquire() which may * free a dirhash structure that was recycled by ufsdirhash_recycle(). * * The dirhash lock may be held across io operations. * * WITNESS reports a lock order reversal between the bufwait lock * and the dirhash lock. However, this specific reversal will not * cause a deadlock. To get a deadlock, one would have to lock a * buffer followed by the dirhash while a second thread locked a * buffer while holding the dirhash lock. The second order can happen * under a shared or exclusive vnode lock for the associated directory * in lookup(). The first order, however, can only happen under an * exclusive vnode lock (e.g. unlink(), rename(), etc.). Thus, for * a thread to be doing a bufwait - dirhash order, it has to hold * an exclusive vnode lock. That exclusive vnode lock will prevent * any other threads from doing a dirhash - bufwait order. */ -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: lock order reversal bufwait/dirhash
On 9 Jun 2010, at 12:58, John Baldwin wrote: On Wednesday 09 June 2010 3:51:52 am Bernd Walter wrote: Got this during installworld (source on NFS, destination UFS on CF-card) Source is current checked out yesterday. lock order reversal: 1st 0xc28b85b4 bufwait (bufwait) @ /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575 2nd 0xc343f000 dirhash (dirhash) @ /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283 KDB: stack backtrace: Known false positive. From ufs_dirhash.c: /* * Locking: * * The relationship between inode and dirhash is protected either by an * exclusive vnode lock or the vnode interlock where a shared vnode lock * may be used. The dirhash_mtx is acquired after the dirhash lock. To * handle teardown races, code wishing to lock the dirhash for an inode * when using a shared vnode lock must obtain a private reference on the * dirhash while holding the vnode interlock. They can drop it once they * have obtained the dirhash lock and verified that the dirhash wasn't * recycled while they waited for the dirhash lock. * * ufsdirhash_build() acquires a shared lock on the dirhash when it is * successful. This lock is released after a call to ufsdirhash_lookup(). * * Functions requiring exclusive access use ufsdirhash_acquire() which may * free a dirhash structure that was recycled by ufsdirhash_recycle(). * * The dirhash lock may be held across io operations. * * WITNESS reports a lock order reversal between the bufwait lock * and the dirhash lock. However, this specific reversal will not * cause a deadlock. To get a deadlock, one would have to lock a * buffer followed by the dirhash while a second thread locked a * buffer while holding the dirhash lock. The second order can happen * under a shared or exclusive vnode lock for the associated directory * in lookup(). The first order, however, can only happen under an * exclusive vnode lock (e.g. unlink(), rename(), etc.). Thus, for * a thread to be doing a bufwait - dirhash order, it has to hold * an exclusive vnode lock. That exclusive vnode lock will prevent * any other threads from doing a dirhash - bufwait order. */ Can we tell witness not to complain then? Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
