Date: Tue, 25 May 2004 09:48:29 +0200 From: Daniel Lang <dl@leo.org> To: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> Cc: freebsd-current@freebsd.org Subject: Re: LOR: tcpinp and tcp Message-ID: <20040525074829.GB30503@atrbg11.informatik.tu-muenchen.de> In-Reply-To: <20040512204829.T8831@ury.york.ac.uk> References: <20040512204829.T8831@ury.york.ac.uk>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Hi, Gavin Atkinson wrote on Wed, May 12, 2004 at 08:59:14PM +0100: [..] > It looks like this LOR has been reported once before, in early January. It > seems to still be an issue. This is with top-of-tree CURRENT. It's not a > known lock according to the LOR page. > > lock order reversal > 1st 0xc2d7a2ac inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:717 > 2nd 0xc08b230c tcp (tcp) @ /usr/src/sys/netinet/tcp_usrreq.c:616 > Stack backtrace: [..] I just came across this one, as well. It is now mentioned on the Zabbadoz LOR-page, but still as "unknown". Here is my stack: [..] > lock order reversal > 1st 0xc6840630 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:717 > 2nd 0xc076d98c tcp (tcp) @ /usr/src/sys/netinet/tcp_usrreq.c:616 > Stack backtrace: > backtrace(0,ffffffff,c0747858,c0747bc8,c0712e1c) at backtrace+0x12 > witness_checkorder(c076d98c,9,c06e30f1,268) at witness_checkorder+0x593 > _mtx_lock_flags(c076d98c,0,c06e30f1,268) at _mtx_lock_flags+0x67 > tcp_usr_rcvd(c687e780,80) at tcp_usr_rcvd+0x1b > soreceive(c687e780,d7e61b2c,d7e61b38,d7e61b30,0) at soreceive+0x865 > nfsrv_rcv(c687e780,c6241b80,4) at nfsrv_rcv+0x83 > sowakeup(c687e780,c687e7cc) at sowakeup+0x71 > tcp_input(c199ec00,14,0,14,812a9f83) at tcp_input+0x12ba > ip_input(c199ec00) at ip_input+0x83a > netisr_processqueue(c076c858,c4392580,c198ae00,d7e61d1c,c05355a8) at netisr_processqueue+0x6e > swi_net(0) at swi_net+0x85 > ithread_loop(c198ae00,d7e61d48,c198ae00,c0535404,0) at ithread_loop+0x1a4 > fork_exit(c0535404,c198ae00,d7e61d48) at fork_exit+0xa8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xd7e61d7c, ebp = 0 --- [..] It did not cause a panic and appeared to do no harm. Maybe this turns out a false positive as well. Can anybody confirm this? Best regards, Daniel -- IRCnet: Mr-Spock - Eddie would go! - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ [-- Attachment #2 --] 0s *H d0`10 + 0 *H 0 0#0 *H 0r10 UDE10UMuenchen10 U TUM10 UIN10URBG-Benutzer-CA10 *H ca@in.tum.de0 040423131558Z 050531000000Z0w10 UDE10UMuenchen10 U TUM10 UIN10UDaniel Lang1$0" *H daniel.lang@in.tum.de0"0 *H 0 W}%Iomp:+bA4W@UI|ܬ.!fD4C=Fց`٤{5dh:'&4M^O 7sz,>@݁</)>D"HoEIm{0o 5287iť1{mX2E ͧBQ5e[3;-+|L-tY=?T͒~ 00U0 0UrUqBngȱ\X^f0U#06$9fG=;òfEmk0i10 UDE10UMuenchen10 U TUM10 UIN10 URBG-CA10 *H ca@in.tum.de0U0U%0++0U0langd@in.tum.dedaniel.lang@in.tum.delangd@informatik.tu-muenchen.de%daniel.lang@informatik.tu-muenchen.delangd@cs.tum.edudaniel.lang@cs.tum.edu dl@leo.org0 U0 0;U40200.,*http://ca.in.tum.de/crls/g2/userca_crl.crl0 `HB0 `HB Dieses Zertifikat wurde ausgestellt fuer Daniel Lang von der RBG-Benutzer-CA (2.Generation), Fakultaet fuer Informatik der Technischen Universitaet Muenchen.06 `HB)'http://ca.in.tum.de/cgi-bin/userca-rev?02 `HB%#http://ca.in.tum.de/cgi-bin/ca-rev?0, `HBhttp://ca.in.tum.de/policies/0GU @0>0< +>eH0+0)+http://ca.in.tum.de/policies/0 *H h[5BC1JkG[ūp+mZ#Ry6JkF]Oj_L\!CL\<3rڅ< [q+NvmS %tȠ>&mDx) Pt(:'6D-蕡JznefLG< zc%$sqW$CgCjb lL|(auZg;#aK900ʠ0 *H 0i10 UDE10UMuenchen10 U TUM10 UIN10 URBG-CA10 *H ca@in.tum.de0 040414113634Z 090601000000Z0p10 UDE10UMuenchen10 U TUM10 UIN10U RBG-Server-CA10 *H ca@in.tum.de0"0 *H 0 ~;rpo1ĴPNۇQ2Tx qeÿ4k3l ffuVir嫡h(LuLw,)X餈;O_qE>(7XfLr!wx|܇MF̈́vUEQޯ$-n = yT AϴB>kc^]\SuX;{{4LN*L8Vupv L35*)& 00U00U68:҃-0U#0/Wm&
