Date: Tue, 8 Sep 2009 23:42:13 +0400 From: pluknet <pluknet@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: freebsd-emulation@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: acquiring duplicate lock of same type: "ftlk" Message-ID: <a31046fc0909081242v7e1b8f98t72a6df8b9d37a960@mail.gmail.com> In-Reply-To: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com> <a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com> <20090908091114.GH47688@deviant.kiev.zoral.com.ua> <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/9/8 Attilio Rao <attilio@freebsd.org>:
> 2009/9/8 Kostik Belousov <kostikbel@gmail.com>:
>> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
>>> lock order reversal:
>>> =A01st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:=
497
>>> =A02nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
>>> at db_trace_self_wrapper+0x26
>>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
>>> kdb_backtrace+0x29
>>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
>>> _witness_debugger+0x25
>>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder=
+0x839
>>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
>>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
>>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
>>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_loo=
kup+0x3dd
>>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
>>> at VOP_CACHEDLOOKUP_APV+0xc5
>>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
>>> vfs_cache_lookup+0xd6
>>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
>>> VOP_LOOKUP_APV+0xe5
>>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
>>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
>>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_=
alternate
>>> _path+0x1cd
>>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
>>> linux_emul_convpath+0x3c
>>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_o=
pen+0x41
>>> syscall(e8214d38) at syscall+0x2b4
>>> Xint0x80_syscall() at Xint0x80_syscall+0x20
>>> --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D
>>> 0xbfbfbd1c, ebp =3D 0xbfbfbd6c ---
>>> acquiring duplicate lock of same type: "ftlk"
>>> [...]
>>
>> The second LOR actually exposes the right order. It would be interesting
>> to look up the point where the other order is established.
>
> You would manually patch the witness static table with this order and
> the opposite will show, when happening.
>
I've patched witness order table, and still no opposite case,
nor any pseudofs related LORs at all.
{ "pseudofs", &lock_class_lockmgr },
{ "allproc", &lock_class_sx },
{ NULL, NULL },
Seen orders with pseudofs:
"ufs","pseudofs"
"pseudofs","allproc"
"pseudofs","process lock"
"pseudofs","vnode interlock"
"pseudofs","struct mount mtx"
"pseudofs","UMA zone"
"pseudofs","sleep mtxpool"
"pseudofs","Name Cache"
"pseudofs","vnode_free_list"
"pseudofs","pfs_node"
"pseudofs","pfs_vncache"
Something else?
--=20
wbr,
pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a31046fc0909081242v7e1b8f98t72a6df8b9d37a960>