Re: lock order reversals on 10.0-ALPHA4

From: Matthew Fleming <mdf_at_FreeBSD.org>
Date: Sun, 6 Oct 2013 08:22:27 -0700
On Sun, Oct 6, 2013 at 6:44 AM, Julian H. Stacey <jhs_at_berklix.com> wrote:

> With:
> FreeBSD lapr.js.berklix.net 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0
> r255933: Sun Sep 29 02:50:54 UTC 2013
> root_at_snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>
> At boot dmesg shows several lock order reversals, eg
>
> ------
> Trying to mount root from ufs:/dev/ad4s2a [rw]...
> ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny,
> logging disabled
> lock order reversal:
>  1st 0xfffffe00a6e26b48 bufwait (bufwait) _at_
> /usr/src/sys/kern/vfs_bio.c:3059
>  2nd 0xfffff80005cf8400 dirhash (dirhash) _at_
> /usr/src/sys/ufs/ufs/ufs_dirhash.c:284
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe00c8f3d3f0
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00c8f3d4a0
> witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe00c8f3d530
> _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe00c8f3d570
> ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfffffe00c8f3d5b0
> ufs_direnter() at ufs_direnter+0x688/frame 0xfffffe00c8f3d670
> ufs_makeinode() at ufs_makeinode+0x573/frame 0xfffffe00c8f3d830
> ufs_symlink() at ufs_symlink+0x32/frame 0xfffffe00c8f3d880
> VOP_SYMLINK_APV() at VOP_SYMLINK_APV+0xf0/frame 0xfffffe00c8f3d8b0
> kern_symlinkat() at kern_symlinkat+0x23e/frame 0xfffffe00c8f3dae0
> amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe00c8f3dbf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00c8f3dbf0
> --- syscall (57, FreeBSD ELF64, sys_symlink), rip = 0x800888ffa, rsp =
> 0x7fffffffca58, rbp = 0x7fffffffdc10 ---
> lock order reversal:
>  1st 0xfffff800881b9d50 ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:851
>  2nd 0xfffff800881b99a0 devfs (devfs) _at_ /usr/src/sys/kern/vfs_subr.c:2099
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe00c8ed93d0
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00c8ed9480
> witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe00c8ed9510
> __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfffffe00c8ed9640
> vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe00c8ed9660
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe00c8ed9690
> _vn_lock() at _vn_lock+0xab/frame 0xfffffe00c8ed9700
> vget() at vget+0x70/frame 0xfffffe00c8ed9750
> devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe00c8ed97a0
> devfs_root() at devfs_root+0x43/frame 0xfffffe00c8ed97d0
> vfs_donmount() at vfs_donmount+0x115e/frame 0xfffffe00c8ed9aa0
> sys_nmount() at sys_nmount+0x72/frame 0xfffffe00c8ed9ae0
> amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe00c8ed9bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00c8ed9bf0
> --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a9dd7a, rsp =
> 0x7fffffffccb8, rbp = 0x7fffffffd220 ---
> ----
>
> Those two LORs are well-known and at least the fist is definitely a false
positive.  They're rather tricky to fix; there's been previous discussion.

The first one is #261 at http://sources.zabbadoz.net/freebsd/lor.html .
 The second one is probably #280.

Cheers,
matthew
Received on Sun Oct 06 2013 - 13:22:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:42 UTC