Date: Tue, 8 Sep 2009 12:11:14 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: pluknet <pluknet@gmail.com> Cc: freebsd-emulation@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: acquiring duplicate lock of same type: "ftlk" Message-ID: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> In-Reply-To: <a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com> References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com> <a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--BqNvIJgrK1/MQy2W Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: > 2009/8/27 pluknet <pluknet@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" > > =9A1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex= .c:177 > > =9A2nd ftlk @ /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_debu= gger+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_g= et0+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 =3D 0x28799533, esp = =3D > > 0xbfbfc0cc, ebp =3D 0x4000001 --- > > > > =46rom what dchagin@ 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. >=20 > This time seeing this LOR again but with another one just before. > lock order reversal: > 1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497 > 2nd 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+0= x839 > _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_looku= p+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_al= ternate > _path+0x1cd > linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at > linux_emul_convpath+0x3c > linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_ope= n+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" > [...] >=20 > 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 f= lash). The second LOR actually exposes the right order. It would be interesting to look up the point where the other order is established. --BqNvIJgrK1/MQy2W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkqmH7IACgkQC3+MBN1Mb4hWsgCg9r/UK/ONeVF1VI0tse7z9g++ ZhkAn27cjfb6rsT7bOd5D+M2laBw4Sjg =l0qZ -----END PGP SIGNATURE----- --BqNvIJgrK1/MQy2W--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090908091114.GH47688>