Re: acquiring duplicate lock of same type: "ftlk"

On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
> 2009/8/27 pluknet <pluknet_at_gmail.com>:
> > Hi.
> >
> > Got it on FreeBSD 9.0-CURRENT while been running in Xorg, don't know
> > where exactly.
> >
> > Acquiring duplicate lock of same type: "ftlk"
> >  1st ftlk _at_ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177
> >  2nd ftlk _at_ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c07fd8ea,ea393b58,c060a145,c05fac1b,c08007b2,...)
> > at db_trace_self_wrapper+0x26
> > kdb_backtrace(c05fac1b,c08007b2,c0b49757,c58ead20,ea393bb4,...) at
> > kdb_backtrace+0x29
> > _witness_debugger(c08007b2,c0b49793,c0b49757,cb,0,...) at _witness_debugger+0x25
> > witness_checkorder(c9bba780,9,c0b49757,cb,0,...) at witness_checkorder+0x469
> > _sx_xlock(c9bba780,0,c0b49757,cb,0,...) at _sx_xlock+0x85
> > futex_get0(c0609f8c,c09cc7a8,c9ac7764,c09cc7a8,c084df3c,...) at futex_get0+0x116
> > linux_sys_futex(c9ac76c0,ea393cf8,ea393d18,ea393d1c,c0b4cf40,...) at
> > linux_sys_futex+0x6f
> > syscall(ea393d38) at syscall+0x2b4
> > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x28799533, esp =
> > 0xbfbfc0cc, ebp = 0x4000001 ---
> >
> >
From what dchagin_at_ told me, the LOR is unavoidable since he has to
acquire two sx locks of the same name. On the other hand, second sx lock
is not visible to any thread except the current one, so the LOR should
be innocent.

> 
> This time seeing this LOR again but with another one just before.
> lock order reversal:
>  1st 0xc75365b8 pseudofs (pseudofs) _at_ /usr/src/sys/kern/vfs_lookup.c:497
>  2nd 0xc088ea3c allproc (allproc) _at_ /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_lookup+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_open+0x41
> syscall(e8214d38) at syscall+0x2b4
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
> acquiring duplicate lock of same type: "ftlk"
> [...]
> 
> I'm running head from 08/26.
> There were recent changes in pseudofs. Could it be fixed?
> Looks like it's connected to running firefox3 with linprocfs (for adobe flash).

The second LOR actually exposes the right order. It would be interesting
to look up the point where the other order is established.