Bug 122588 - [lor] 4 Lock Order Reversal (pseudofs/ufs/vfs)
Summary: [lor] 4 Lock Order Reversal (pseudofs/ufs/vfs)
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-08 23:10 UTC by raoul
Modified: 2018-05-29 10:01 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description raoul 2008-04-08 23:10:00 UTC
Hi,

I found some LOR looking at my dmesg.
the system:
a Sony s5 laptop (intel 770 at 2 ghz);
1G ram running current dated from: 2008 April 2.

If these LOR are well known, please simply forget this message.

lock order reversal:
 1st 0xc496ce08 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2045
 2nd 0xc4ad0614 devfsmount (devfsmount) @ /usr/src/sys/fs/devfs/devfs_vnops.c:201
KDB: stack backtrace:
db_trace_self_wrapper(c0b0fe6d,e2f95bbc,c07add7e,c0b1235f,c4ad0614,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0b1235f,c4ad0614,c0b03801,c0b03801,c0b03842,...) at kdb_backtrace+0x29
witness_checkorder(c4ad0614,9,c0b03842,c9,c7,...) at witness_checkorder+0x6de
_sx_xlock(c4ad0614,0,c0b03842,c9,c4ad0614,...) at _sx_xlock+0x7d
devfs_allocv(c4b0ec00,c4b26000,e2f95c28,c4627cc0,c0b180c1,...) at devfs_allocv+0x144
devfs_root(c4b26000,2,c0c83018,c4627cc0,ca,...) at devfs_root+0x51
set_rootvnode(c0c83000,0,c0b180c1,5f5,c07eb350,...) at set_rootvnode+0x2b
vfs_mountroot(c0c30730,4,c0b07c9a,264,ffd7ff9d,...) at vfs_mountroot+0x356
start_init(0,e2f95d38,c0b0960f,30d,c4625cf8,...) at start_init+0x65
fork_exit(c073b5f0,0,e2f95d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe2f95d70, ebp = 0 ---

Trying to mount root from ufs:/dev/ad4s4a

lock order reversal:
 1st 0xc496c978 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2045
 2nd 0xc4b26000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364
KDB: stack backtrace:
db_trace_self_wrapper(c0b0fe6d,e2f959b4,c07add7e,c0b1235f,c4b26000,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0b1235f,c4b26000,c0b181bf,c0b181bf,c0b1875c,...) at kdb_backtrace+0x29
witness_checkorder(c4b26000,1,c0b1875c,16c,e2f959f4,...) at witness_checkorder+0x6de
_lockmgr_args(c4b26000,20001,c4b26030,0,ffffffff,...) at _lockmgr_args+0x1d5
vfs_busy(c4b26000,0,0,c4627cc0,e2f95b3c,...) at vfs_busy+0x1b0
lookup(e2f95b24,c0b17e6f,d8,c0,c461132c,...) at lookup+0x7bf
namei(e2f95b24,e2f95b28,c07ad55c,e2f95b30,c0c828a8,...) at namei+0x44b
kern_unlinkat(c4627cc0,ffffff9c,c0b184fe,1,e2f95c5c,...) at kern_unlinkat+0x46
kern_unlink(c4627cc0,c0b184fe,1,630,0,...) at kern_unlink+0x27
vfs_mountroot_try(c0b186b8,c0b069cb,c0aff32c,1,c07eb350,...) at vfs_mountroot_try+0x476
vfs_mountroot(c0c30730,4,c0b07c9a,264,ffd7ff9d,...) at vfs_mountroot+0x418
start_init(0,e2f95d38,c0b0960f,30d,c4625cf8,...) at start_init+0x65
fork_exit(c073b5f0,0,e2f95d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe2f95d70, ebp = 0 ---

start_init: trying /sbin/init

lock order reversal:
 1st 0xc462b044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3111
 2nd 0xc496c730 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2045
KDB: stack backtrace:
db_trace_self_wrapper(c0b0fe6d,e2f959e0,c07add7e,c0b1235f,c496c730,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0b1235f,c496c730,c0b0727e,c0b0727e,c0b1875c,...) at kdb_backtrace+0x29
witness_checkorder(c496c730,1,c0b1875c,7fd,c0b307d9,...) at witness_checkorder+0x6de
_lockmgr_args(c496c730,30041,c496c760,0,ffffffff,...) at _lockmgr_args+0x1d5
ffs_lock(e2f95a88,c0b32281,c0b069c9,30041,c496c6d8,...) at ffs_lock+0x72
VOP_LOCK1_APV(c0be6ba0,e2f95a88,c0bff060,c496c6d8,30041,...) at VOP_LOCK1_APV+0xa5
_vn_lock(c496c6d8,30041,c0b1875c,7fd,c0b0bba3,...) at _vn_lock+0x5b
vget(c496c6d8,30041,c4627cc0,4a9,c1c5f180,...) at vget+0xa1
vnode_pager_lock(c1c5f200,0,c0b2f8d7,127,e2f95be8,...) at vnode_pager_lock+0x1ad
vm_fault(c462b000,80d3000,2,8,80d3000,...) at vm_fault+0x1df
trap_pfault(5,0,c0b3e3ed,2c4,c4625cf8,...) at trap_pfault+0x118
trap(e2f95d38) at trap+0x259
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 ---

WARNING: attempt to net_add_domain(bluetooth) after domainfinalize()
WARNING: attempt to net_add_domain(netgraph) after domainfinalize()
lock order reversal:
 1st 0xc4ba7978 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:2045
 2nd 0xc4b25a70 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364
KDB: stack backtrace:
db_trace_self_wrapper(c0b0fe6d,e6ee3a14,c07add7e,c0b1235f,c4b25a70,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0b1235f,c4b25a70,c0b181bf,c0b181bf,c0b1875c,...) at kdb_backtrace+0x29
witness_checkorder(c4b25a70,1,c0b1875c,16c,e6ee3a54,...) at witness_checkorder+0x6de
_lockmgr_args(c4b25a70,20001,c4b25aa0,0,ffffffff,...) at _lockmgr_args+0x1d5
vfs_busy(c4b25a70,10,0,c4b74aa0,0,...) at vfs_busy+0x1b0
vfs_donmount(810e080,c,e6ee3c70,c4c1f180,810b530,...) at vfs_donmount+0xdbc
nmount(c4b74aa0,e6ee3cfc,c,c0b12fc9,c0bc7630,...) at nmount+0xb2
syscall(e6ee3d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280d727b, esp = 0xbfbfe96c, ebp = 0xbfbfedb8 ---


best regards

raoul
rmgls@free.fr

How-To-Repeat: simply booting the machine, all the time.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2008-04-14 05:18:32 UTC
Responsible Changed
From-To: freebsd-i386->freebsd-bugs

This does not sound i386-specific.
Comment 2 Enji Cooper freebsd_committer freebsd_triage 2015-11-15 02:54:26 UTC
Most of these LORs are known, but the 2nd and 4th LORs look interesting (I don't remember seeing LORs with vfslock and pseudofs recently).

Reassigning to -fs@ for triage.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:56 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 4 Andriy Gapon freebsd_committer freebsd_triage 2018-05-29 10:01:44 UTC
The report is just too old.