Date: Wed, 26 Jun 2002 00:28:48 -0400 From: Don Bowman <don@sandvine.com> To: 'Jonathan Lemon' <jlemon@flugsvamp.com>, "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org> Subject: RE: panic in syncache/rtfree with 4.6, BUG, problem found Message-ID: <FE045D4D9F7AED4CBFF1B3B813C853376765D3@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
It would appear that in syncache_respond(), which calls
ip_output(), there is a way that the ip_output() can
re-enter the syncache code.
For example,
ipintr()
ip_input()
tcp_input()
syncache_add()
syncache_respond()
ip_output()
ip_input()
tcp_input()
syncache_badack()
and then kaboom. syncache_badack() will do a syncache_drop(),
which deletes the 'sc' entry, which syncache_respond() is
still holding onto, which, on return, will cause a crash.
Now, the 64K question is, can I avoid this with a change
to my ipfw rules?
00100 allow ip from any to any via lo0
00101 allow ip from me to any
00102 allow ip from any to me
00105 fwd 127.0.0.1,9000 tcp from any to any 5000
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65535 allow ip from any to any
In my test I'm doing connections to an arbitrary IP, port
5000, and using fwd to divert them locally (a transparent
proxy) to port 9000. Is it the ipfw rule on ip_output that
comes back to me on ip_input()? Or is it some other mechanism?
What is the suggested fix? Obviously this could recurse
for a long time and blow the stack in addition to just
being really hard on the data pointers.
One fix would be to make it so no state was held
over calls to syncache_respond().
Another would be to somehow defer the ip_output() until
we were outside the syncache code.
I'm seeing this crash reasonably frequently in a few systems
here (most frequent is every ~30seconds or so with a test,
least frequent is every ~day or so under 'normal' use).
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc01bf5ef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc01bfa48 in poweroff_wait (junk=0xc032f787, howto=-182903712)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc021c492 in syncache_badack (inc=0xf98d9bec)
at /usr/src/sys/netinet/tcp_syncache.c:532
#4 0xc0217eaa in tcp_input (m=0xc37f5300, off0=20, proto=6)
at /usr/src/sys/netinet/tcp_input.c:732
#5 0xc0213bf3 in ip_input (m=0xc37f5300)
at /usr/src/sys/netinet/ip_input.c:841
#6 0xc0215553 in ip_output (m0=0xc37f5300, opt=0x0, ro=0xf6291ed8, flags=0,
imo=0x0) at /usr/src/sys/netinet/ip_output.c:720
#7 0xc021d2c9 in syncache_respond (sc=0xf6291ea0, m=0xc37f5300)
at /usr/src/sys/netinet/tcp_syncache.c:1277
#8 0xc021cf20 in syncache_add (inc=0xf98d9de4, to=0xf98d9e58,
th=0xc3b34024,
sop=0xf98d9de0, m=0xc37f5300) at
/usr/src/sys/netinet/tcp_syncache.c:1084
#9 0xc0217f90 in tcp_input (m=0xc37f5300, off0=20, proto=6)
at /usr/src/sys/netinet/tcp_input.c:827
#10 0xc0213bf3 in ip_input (m=0xc37f5300)
at /usr/src/sys/netinet/ip_input.c:841
#11 0xc0213c67 in ipintr () at /usr/src/sys/netinet/ip_input.c:869
#12 0xc02d7061 in swi_net_next ()
#13 0xc01c10d4 in issignal (p=0xf27e5ee0) at
/usr/src/sys/kern/kern_sig.c:1252
#14 0xc02e54e7 in trap (frame={tf_fs = 47, tf_es = 673054767,
tf_ds = 135921711, tf_edi = 135665276, tf_esi = 135901184,
tf_ebp = 135933388, tf_isp = -108159020, tf_ebx = 135607296,
tf_edx = 496, tf_ecx = 256, tf_eax = 197198436, tf_trapno = 7,
tf_err = 0, tf_eip = 134735518, tf_cs = 31, tf_eflags = 518,
tf_esp = 135933352, tf_ss = 47}) at /usr/src/sys/sys/signalvar.h:244
#15 0xc02d703a in doreti_ast ()
#16 0x807ccb8 in ?? ()
#17 0x804fd18 in ?? ()
#18 0x80501c2 in ?? ()
#19 0x804b967 in ?? ()
#20 0x804bf1b in ?? ()
#21 0x807a34a in ?? ()
#22 0x807a249 in ?? ()
#23 0x2817644f in ?? ()
#24 0x0 in ?? ()
(kgdb)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C853376765D3>