machine locks with PF (without using user dependent rules)

[Emanuel Strobl]

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 try

No, I don't have pfsync in the kernel, also I don't have modules on that box.

> 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. 

I tried your patch, no changes. I can panic the box with "pfctl -F all 
-f /etc/pfconf" regardless of the debug.mpsafenet state.
But I don't get any panics with debug.mpsafenet=1 while normal operating.
And I also cannot see any rule behaviour difference any more. For now it looks 
to me as if it's only the pfctl command which can panic the box, but I'll see 
the next days.

Here is the latest traceback with your patch:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xdeadc1d7
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc047b748
stack pointer           = 0x10:0xcc6948fc
frame pointer           = 0x10:0xcc694904
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 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 
pf_state_compare_ext_gwy+0x18
pf_state_tree_ext_gwy_RB_FIND(c17ed0c4,cc6949ac,0,c17ed000,cc694ab8) at 
pf_state_tree_ext_gwy_RB_FIND+0x29
pf_find_state_recurse(c17ed000,cc6949ac,1,c1045ae0,c1743300) at 
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 
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
--- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 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.

Feel free to ask me whaetever you want me to do, at the moment I have the 
machine semiproductive and spare time :) Just lacking hacking knowledge :(

-Harry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050208/93f029b3/attachment.bin