Date: Wed, 19 Aug 2009 12:50:29 -0500 From: "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> To: current@freebsd.org Cc: bzeeb+freebsd+lor@zabbadoz.net Subject: Re: various vfs LORs Message-ID: <20090819175029.GA90205@keira.kiwi-computer.com> In-Reply-To: <20090819161817.GA89704@keira.kiwi-computer.com> References: <20090819161817.GA89704@keira.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 19, 2009 at 06:00:31PM +0100, Bruce Cran wrote: > On Wed, Aug 19, 2009 at 11:18:17AM -0500, Rick C. Petty wrote: > > > Upon every restart, I see a few LORs. I couldn't find PRs for any of them. > > See attached dmesg below. Should I submit a PR for each of them or one PR > > for all five? > > You should check http://sources.zabbadoz.net/freebsd/lor.html first > before submitting PRs, to see if they're known. Thanks, I'll update my post accordingly... > % uname -a > FreeBSD myhost 8.0-BETA2 FreeBSD 8.0-BETA2 #4 r196381M: Wed Aug 19 10:06:03 CDT 2009 root@myhost:/usr/obj/usr/src/sys/GENERIC amd64 <snip> This is LOR #280 with slightly different line numbers and backtrace: > lock order reversal: > 1st 0xffffff0002e48620 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200 > 2nd 0xffffff0002e48d80 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+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xcf3 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x7b > devfs_allocv() at devfs_allocv+0x100 > devfs_root() at devfs_root+0x48 > vflush() at vflush+0x4c > devfs_unmount() at devfs_unmount+0x46 > dounmount() at dounmount+0x2e6 > unmount() at unmount+0x27e > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a09ec, rsp = 0x7fffffffe248, rbp = 0 --- LOR #261 was already reported: > lock order reversal: > 1st 0xffffff80a51147e8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 > 2nd 0xffffff000439b400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 This LOR doesn't seem to be reported anywhere: > lock order reversal: > 1st 0xffffff00046de7f8 nfs (nfs) @ /usr/src/sys/kern/vfs_syscalls.c:4097 > 2nd 0xffffff80a5129968 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:1835 > 3rd 0xffffff00046de620 nfs (nfs) @ /usr/src/sys/nfsclient/nfs_node.c:161 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xcf3 > nfs_nget() at nfs_nget+0x1c9 > nfs_readdirplusrpc() at nfs_readdirplusrpc+0x7cc > nfs_doio() at nfs_doio+0x617 > nfs_bioread() at nfs_bioread+0xa9f > nfs_readdir() at nfs_readdir+0x85 > kern_getdirentries() at kern_getdirentries+0x12e > getdirentries() at getdirentries+0x23 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8009d11dc, rsp = 0x7fffffffc3a8, rbp = 0x1 --- This one has not been reported either: > lock order reversal: > 1st 0xffffff000412b270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 > 2nd 0xffffff00043e6098 ufs (ufs) @ /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+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xcf3 > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x7b > vfs_msync() at vfs_msync+0xa3 > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80e7b74d30, rbp = 0 --- This one is not an LOR but should probably be investigated nonetheless: > acquiring duplicate lock of same type: "ftlk" > 1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 > 2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x8ef > _sx_xlock() at _sx_xlock+0x55 > futex_get0() at futex_get0+0xfe > linux_sys_futex() at linux_sys_futex+0x96 > ia32_syscall() at ia32_syscall+0x19c > Xint0x80_syscall() at Xint0x80_syscall+0x95 > --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28799533, rsp = 0xffffaecc, rbp = 0x4000001 --- -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090819175029.GA90205>