lock order reversals in RELENG_8

Marius Nünnerich marius at nuenneri.ch
Thu Dec 31 11:17:10 UTC 2009


On Thu, Dec 31, 2009 at 12:10, Pete French <petefrench at ticketswitch.com> wrote:
> am still trying to get the machine which ocks up to lock up
> when I have DDb, KDB and WITNESS in the ernel. It's not locked yet
> but I have got the following in dmesg...
>
> lock order reversal:
>  1st 0xffffff8052321e50 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559
>  2nd 0xffffff000384a800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2c
> witness_checkorder() at witness_checkorder+0x66f
> _sx_xlock() at _sx_xlock+0x35
> ufsdirhash_acquire() at ufsdirhash_acquire+0x33
> ufsdirhash_remove() at ufsdirhash_remove+0x18
> ufs_dirremove() at ufs_dirremove+0x161
> ufs_remove() at ufs_remove+0x92
> VOP_REMOVE_APV() at VOP_REMOVE_APV+0x34
> kern_unlinkat() at kern_unlinkat+0x252
> syscall() at syscall+0x19d
> Xfast_syscall() at Xfast_syscall+0xe1
> --- syscall (10, FreeBSD ELF64, unlink), rip = 0x80072a28c, rsp = 0x7fffffffe418, rbp = 0x7fffffffef6e ---
> lock order reversal:
>  1st 0xffffff003e230d80 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1058
>  2nd 0xffffff003e2307f8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2c
> witness_checkorder() at witness_checkorder+0x66f
> __lockmgr_args() at __lockmgr_args+0x475
> vop_stdlock() at vop_stdlock+0x39
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46
> _vn_lock() at _vn_lock+0x47
> vget() at vget+0x56
> devfs_allocv() at devfs_allocv+0x103
> devfs_root() at devfs_root+0x48
> vfs_donmount() at vfs_donmount+0xf43
> nmount() at nmount+0x63
> syscall() at syscall+0x19d
> Xfast_syscall() at Xfast_syscall+0xe1
> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007b062c, rsp = 0x7fffffffdd28, rbp = 0x
>

I think this is LOR #261 and therefore harmless.
http://sources.zabbadoz.net/freebsd/lor.html


More information about the freebsd-stable mailing list