Date: Tue, 22 Mar 2005 19:32:30 +0100 From: Emanuel Strobl <emanuel.strobl@gmx.net> To: pyunyh@gmail.com Cc: pf@freebsd.org Subject: PF panick patch doesn't work [Was: Re: pf panic trace] Message-ID: <200503221932.43408@harrymail> In-Reply-To: <20050312050722.GC60892@kt-is.co.kr> References: <20050212061756.GF4769@kt-is.co.kr> <200503111712.36310@harrymail> <20050312050722.GC60892@kt-is.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1881086.IdIy2KLtMM Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Samstag, 12. M=E4rz 2005 06:07 schrieb Pyun YongHyeon: > On Fri, Mar 11, 2005 at 05:12:31PM +0100, Emanuel Strobl wrote: > > Am Freitag, 11. M?rz 2005 16:19 schrieb Emanuel Strobl: > > > Am Freitag, 11. M?rz 2005 14:52 schrieb Daniel Hartmeier: > > > > block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp > > > > all > > > > > > > > This is valid syntax and pfctl loads the rule, but the functionali= ty > > > > is not implemented in kernel yet, i.e. the reply-to option is simp= ly > > > > ignored. > > > > > > Thanks, I tried a very similar rule and after that the box vanished. > > > I went on location (the box paniced but didn't reboot) and installed= a > > > console-server so I can access the box from here and currently I'm > > > baking a debug kernel. > > > I'll notify you if I have a trace! > > > > Here's the original panic message (the non debug kernel) with 5.4-PRE > > one week old: > > Fatal trap 12: page fault while in kernel mode > > fault virtual address =3D 0xc > > fault code =3D supervisor read, page not pre > > instruction pointer =3D 0x8:0xc05ac722 > > stack pointer =3D 0x10:0xcc6919ac > > frame pointer =3D 0x10:0xcc6919e0 > > code segment =3D base 0x0, limit 0xfffff, type > > =3D DPL 0, pres 1, def32 1, gran > > processor eflags =3D interrupt enabled, resume, IO > > current process =3D 34 (swi1: net) > > trap number =3D 12 > > panic: page fault > > Uptime: 1d1h20m33s > > GEOM_MIRROR: Device web: provider mirror/web destroyed. > > GEOM_MIRROR: Device web destroyed. > > ... > > The machine didn't reboot! > > > > > > The following rule panickes the machine: > > block return-icmp(13) in on $SDSL route-to ($SDSL $sdsl_gw) from any to > > $sdsl_net > > > > Here's the trace from 5.4-PRE today: > > panic: m_copym, offset > size of mbuf chain > > KDB: stack backtrace: > > panic(c076ab9a,c174d500,100,cc694a30,0) at panic+0x13c > > m_copym(c1621b00,5dc,5c8,1,14) at m_copym+0x1c7 > > ip_fragment(c1642010,cc694a74,5dc,6,f01) at ip_fragment+0x168 > > pf_route(cc694bf0,c1a10d20,1,c1585000,0) at pf_route+0x767 > > pf_test(1,c1585000,cc694bf0,0,c17554e0) at pf_test+0x7b1 > > pf_check_in(0,cc694bf0,c1585000,1,0) at pf_check_in+0x48 > > pfil_run_hooks(c07f3e60,cc694c9c,c1585000,1,0) at pfil_run_hooks+0x15b > > ip_input(c1621b00,0,c076e621,e6,c07f3f20) at ip_input+0x20f > > netisr_processqueue(cc694cd8,246,c07c8ee0,2,c1508d40) at > > netisr_processqueue+0x15 > > swi_net(0,0,c0762ddc,269,0) at swi_net+0x8d > > ithread_loop(c1526300,cc694d48,c0762bbd,30e,0) at ithread_loop+0x1ff > > fork_exit(c0560640,c1526300,cc694d48) at fork_exit+0xa9 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip =3D 0, esp =3D 0xcc694d7c, ebp =3D 0 --- > > > > If you need more info, on http://www.schmalzbauer.de/statics/phobos you > > can find dmesg and the whole pf.conf > > Hmm, Max and I had seen these kind of traces when pf porting > was in progress. But now I believe we fixed all possible > cases. > > I can't sure but your trace indicates there is a bug in > ip_fragment(). If a packet already set IP_MF flag in ip header, > we would get invalid ip_off in fragmented packet. > And it seems that there is another bug in pf. Since ip_fragment() > can change passed mbuf, we should not use saved copy of it. > Untested patch for CURRENT attached. Hello, I tested your patch against BETA1 (RELENG_5 from today). It applied and=20 compiled but unfortunately doesn't solf the panick. Here's the latest trace: login: panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 35 tid 100031 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> trace Tracing pid 35 tid 100031 td 0xc1515190 kdb_enter(c0765289,c07ca240,c076a9a8,cc6949d8,c1515190) at kdb_enter+0x32 panic(c076a9a8,c1751600,100,cc694a48,0) at panic+0x14d m_copym(c1619b00,5dc,5c8,1,14) at m_copym+0x1c7 ip_fragment(c163a010,cc694a88,5dc,6,f01) at ip_fragment+0x168login: panic:= =20 m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 35 tid 100031 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> trace Tracing pid 35 tid 100031 td 0xc1515190 kdb_enter(c0765289,c07ca240,c076a9a8,cc6949d8,c1515190) at kdb_enter+0x32 panic(c076a9a8,c1751600,100,cc694a48,0) at panic+0x14d m_copym(c1619b00,5dc,5c8,1,14) at m_copym+0x1c7 ip_fragment(c163a010,cc694a88,5dc,6,f01) at ip_fragment+0x168 pf_route(cc694c04,c1a13d20,1,c1588000,0) at pf_route+0x761 pf_test(1,c1588000,cc694c04,0,c1758b20) at pf_test+0x7b1 pf_check_in(0,cc694c04,c1588000,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f3d00,cc694c9c,c1588000,1,0) at pfil_run_hooks+0x15b ip_input(c1619b00,0,c076e42f,e6,c07f3dc0) at ip_input+0x205 netisr_processqueue(cc694cd8,246,c07c8d60,2,c1508d40) at=20 netisr_processqueue+0x15 swi_net(0,0,c0762bea,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c07629cb,30e,0) at ithread_loop+0x1ff fork_exit(c0560290,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 =2D-- trap 0x1, eip =3D 0, esp =3D 0xcc694d7c, ebp =3D 0 --- db> pf_route(cc694c04,c1a13d20,1,c1588000,0) at pf_route+0x761 pf_test(1,c1588000,cc694c04,0,c1758b20) at pf_test+0x7b1 pf_check_in(0,cc694c04,c1588000,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f3d00,cc694c9c,c1588000,1,0) at pfil_run_hooks+0x15b ip_input(c1619b00,0,c076e42f,e6,c07f3dc0) at ip_input+0x205 netisr_processqueue(cc694cd8,246,c07c8d60,2,c1508d40) at=20 netisr_processqueue+0x15 swi_net(0,0,c0762bea,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c07629cb,30e,0) at ithread_loop+0x1ff fork_exit(c0560290,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 =2D-- trap 0x1, eip =3D 0, esp =3D 0xcc694d7c, ebp =3D 0 --- db> Thanks, =2DHarry P.S.: Shall I file a PR? Do you think this will be fixed before 5.4? --nextPart1881086.IdIy2KLtMM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCQGTLBylq0S4AzzwRAhMpAJ47G/mp4/A3nQo9i7eAyF7Bil6ZLQCeO5wJ 0ItsSd+IShmnOomU7U4/eaE= =DucL -----END PGP SIGNATURE----- --nextPart1881086.IdIy2KLtMM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503221932.43408>