Quoting asomers@ on the current list:
"Adding Will at . I think he was working on this LOR at one point"
No idea what a LOR (Lock Order R??) is (yet) but might have
the same cause as the issue I've posted on the current list
earlier today*.
Regards, Florian
*) my trace can also be found under
https://gist.github.com/a342d0381a6b7ac8b313
Am 30. Dezember 2015 01:26:00 MEZ, schrieb Oliver Pinter <oliver.pinter at
hardenedbsd.org>:> Hi All!
>
> I get these new LORs with a recent 10-STABLE (~10-stable from today)
> branch:
>
> LOR1:
>
> [12] lock order reversal:
> [12] 1st 0xfffff8000d1ea7c8 ufs (ufs) @
> /usr/src/sys/kern/vfs_mount.c:1224
> [12] 2nd 0xfffff8000d1eb240 devfs (devfs) @
> /usr/src/sys/kern/vfs_subr.c:2192
> [12] KDB: stack backtrace:
> [12] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe0465ef9170
> [12] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0465ef9220
> [12] witness_checkorder() at witness_checkorder+0xe12/frame
> 0xfffffe0465ef92b0
> [12] __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfffffe0465ef93f0
> [12] vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe0465ef9410
> [12] VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd9/frame 0xfffffe0465ef9440
> [12] _vn_lock() at _vn_lock+0xaa/frame 0xfffffe0465ef94b0
> [12] vget() at vget+0x67/frame 0xfffffe0465ef94f0
> [12] devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe0465ef9540
> [12] devfs_root() at devfs_root+0x43/frame 0xfffffe0465ef9570
> [12] vflush() at vflush+0x78/frame 0xfffffe0465ef96c0
> [12] devfs_unmount() at devfs_unmount+0x38/frame 0xfffffe0465ef96f0
> [12] dounmount() at dounmount+0x524/frame 0xfffffe0465ef9770
> [12] sys_unmount() at sys_unmount+0x3c6/frame 0xfffffe0465ef98a0
> [12] amd64_syscall() at amd64_syscall+0x2a8/frame 0xfffffe0465ef99b0
> [12] Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0465ef99b0
> [12] --- syscall (22, FreeBSD ELF64, sys_unmount), rip > 0x102e573755a,
rsp = 0x62a395ff4318, rbp = 0x62a395ff4470 ---
>
> LOR2:
> [13] lock order reversal:
> [13] 1st 0xfffff8000d3feb78 ufs (ufs) @
> /usr/src/sys/kern/vfs_subr.c:2192
> [13] 2nd 0xfffffe03df2460d8 bufwait (bufwait) @
> /usr/src/sys/ufs/ffs/ffs_vnops.c:262
> [13] 3rd 0xfffff8000d33a5f0 ufs (ufs) @
> /usr/src/sys/kern/vfs_subr.c:2192
> [13] KDB: stack backtrace:
> [13] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe0465ed0b30
> [13] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0465ed0be0
> [13] witness_checkorder() at witness_checkorder+0xe12/frame
> 0xfffffe0465ed0c70
> [13] __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfffffe0465ed0db0
> [13] ffs_lock() at ffs_lock+0x84/frame 0xfffffe0465ed0e00
> [13] VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd9/frame 0xfffffe0465ed0e30
> [13] _vn_lock() at _vn_lock+0xaa/frame 0xfffffe0465ed0ea0
> [13] vget() at vget+0x67/frame 0xfffffe0465ed0ee0
> [13] vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfffffe0465ed0f30
> [13] ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0465ed0fc0
> [13] softdep_sync_buf() at softdep_sync_buf+0xac0/frame
> 0xfffffe0465ed10a0
> [13] ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfffffe0465ed1120
> [13] ffs_truncate() at ffs_truncate+0x6ad/frame 0xfffffe0465ed1300
> [13] ufs_direnter() at ufs_direnter+0x81a/frame 0xfffffe0465ed13c0
> [13] ufs_makeinode() at ufs_makeinode+0x576/frame 0xfffffe0465ed1570
> [13] ufs_create() at ufs_create+0x2d/frame 0xfffffe0465ed1590
> [13] VOP_CREATE_APV() at VOP_CREATE_APV+0xcb/frame 0xfffffe0465ed15c0
> [13] vn_open_cred() at vn_open_cred+0x2c3/frame 0xfffffe0465ed1720
> [13] kern_openat() at kern_openat+0x26d/frame 0xfffffe0465ed18a0
> [13] amd64_syscall() at amd64_syscall+0x2a8/frame 0xfffffe0465ed19b0
> [13] Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0465ed19b0
> [13] --- syscall (499, FreeBSD ELF64, sys_openat), rip > 0x29173acbbaa,
rsp = 0x6a7c0c683d08, rbp = 0x6a7c0c683de0 ---
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"