Date: Tue, 8 Feb 2005 23:52:00 +0100 From: Emanuel Strobl <emanuel.strobl@gmx.net> To: freebsd-stable@freebsd.org Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: machine locks with PF (without using user dependent rules) Message-ID: <200502082352.07209@harrymail> In-Reply-To: <200502081418.14813.max@love2party.net> References: <Pine.NEB.3.96L.1050108165119.43829D-100000@fledge.watson.org> <200502071652.43030@harrymail> <200502081418.14813.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart4984171.rEnDG7qUsI
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Am Dienstag, 8. Februar 2005 14:18 schrieb Max Laier:
> On Monday 07 February 2005 16:52, Emanuel Strobl wrote:
[...]
> Do you have pfsync compiled in? Is it up? If that's the case, can you t=
ry
No, I don't have pfsync in the kernel, also I don't have modules on that bo=
x.
> to reproduce with a kernel without "device pfsync", please? Can you also
> please try the attached diff and see if it turns up anything - though I
> certainly doubt that. Really except to see pfsync being the culprit here=
=2E=20
I tried your patch, no changes. I can panic the box with "pfctl -F all=20
=2Df /etc/pfconf" regardless of the debug.mpsafenet state.
But I don't get any panics with debug.mpsafenet=3D1 while normal operating.
And I also cannot see any rule behaviour difference any more. For now it lo=
oks=20
to me as if it's only the pfctl command which can panic the box, but I'll s=
ee=20
the next days.
Here is the latest traceback with your patch:
=46atal trap 12: page fault while in kernel mode
fault virtual address =3D 0xdeadc1d7
fault code =3D supervisor read, page not present
instruction pointer =3D 0x8:0xc047b748
stack pointer =3D 0x10:0xcc6948fc
frame pointer =3D 0x10:0xcc694904
code segment =3D base 0x0, limit 0xfffff, type 0x1b
=3D DPL 0, pres 1, def32 1, gran 1
processor eflags =3D interrupt enabled, resume, IOPL =3D 0
current process =3D 35 (swi1: net)
[thread pid 35 tid 100031 ]
Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax
db> trace
Tracing pid 35 tid 100031 td 0xc1515190
pf_state_compare_ext_gwy(c17ed000,cc6949ac,cc69492c,c047c2f2,c17ed0c4) at=20
pf_state_compare_ext_gwy+0x18
pf_state_tree_ext_gwy_RB_FIND(c17ed0c4,cc6949ac,0,c17ed000,cc694ab8) at=20
pf_state_tree_ext_gwy_RB_FIND+0x29
pf_find_state_recurse(c17ed000,cc6949ac,1,c1045ae0,c1743300) at=20
pf_find_state_recurse+0x72
pf_test_state_tcp(cc694b00,1,c17ed000,c18aaa00,14) at pf_test_state_tcp+0xb0
pf_test(1,c1585800,cc694bf0,0,c174d260) at pf_test+0x981
pf_check_in(0,cc694bf0,c1585800,1,0) at pf_check_in+0x48
pfil_run_hooks(c07edc20,cc694c9c,c1585800,1,0) at pfil_run_hooks+0x15b
ip_input(c18aaa00,0,c0768929,e6,c07edce0) at ip_input+0x20f
netisr_processqueue(cc694cd8,246,c07c2ca0,2,c1508d40) at=20
netisr_processqueue+0x15
swi_net(0,0,c075d0e9,269,0) at swi_net+0x8d
ithread_loop(c1526300,cc694d48,c075ceca,31e,0) at ithread_loop+0x1ff
fork_exit(c055d000,c1526300,cc694d48) at fork_exit+0xa9
fork_trampoline() at fork_trampoline+0x8
=2D-- trap 0x1, eip =3D 0, esp =3D 0xcc694d7c, ebp =3D 0 ---
> I'm a bit busy these days so I can't do extensive testing myself. It'd be
> a great help if you could verify that I am looking at the right thing.
=46eel free to ask me whaetever you want me to do, at the moment I have the=
=20
machine semiproductive and spare time :) Just lacking hacking knowledge :(
=2DHarry
--nextPart4984171.rEnDG7qUsI
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQBCCUKXBylq0S4AzzwRAmqgAJ9QXpVvwAZ9yxQMp1G0rjDSQKwBGgCdHWRZ
fLSBLo6ZllDqbeX95lJaF7E=
=Orik
-----END PGP SIGNATURE-----
--nextPart4984171.rEnDG7qUsI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502082352.07209>