machine locks with PF (without using user dependent rules)

[Max Laier]

On Monday 07 February 2005 16:52, Emanuel Strobl wrote:
> Resuming work on this, I managed to get a remote console to the box and
> here's what I get with today's RELENG_5 and the following command, also I
> need to set debug.mpsafenet to 0 otherwise my ruleset doesn't work (do what
> it should do and does when set to 0 but not when default 1):
> pfctl -F all -f /etc/pf.conf
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0xdeadc1d7
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc047ac48
> stack pointer           = 0x10:0xd0a44728
> frame pointer           = 0x10:0xd0a44730
> 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         = 1053 (sshd)
> [thread pid 1053 tid 100081 ]
> Stopped at      pf_state_compare_lan_ext+0x18:  movzbl  0xf9(%esi),%eax
> db> trace
> Tracing pid 1053 tid 100081 td 0xc177e190
> pf_state_compare_lan_ext(c176ca00,d0a447d8,d0a44758,c047c095,c176cac0) at
> pf_state_compare_lan_ext+0x18
> pf_state_tree_lan_ext_RB_FIND(c176cac0,d0a447d8,0,c176ca00,d0a448e4) at
> pf_state_tree_lan_ext_RB_FIND+0x29
> pf_find_state_recurse(c176ca00,d0a447d8,0,da7a0000,c0586400) at
> pf_find_state_recurse+0x45
> pf_test_state_tcp(d0a4492c,2,c176ca00,c1746b00,14) at
> pf_test_state_tcp+0xb0 pf_test(2,c1586000,d0a44a1c,c19ff168,c1756720) at
> pf_test+0x981
> pf_check_out(0,d0a44a1c,c1586000,2,c19ff168) at pf_check_out+0x4e
> pfil_run_hooks(c07f05a0,d0a44aa8,c1586000,2,c19ff168) at
> pfil_run_hooks+0x15b ip_output(c1746b00,0,d0a44a74,0,0) at ip_output+0x3ef
> tcp_output(c1a02710,c1744900,c076ed93,280,0) at tcp_output+0x984
> tcp_usr_send(c1b5fdec,0,c1744900,0,0) at tcp_usr_send+0x239
> sosend(c1b5fdec,0,d0a44c84,c1744900,0) at sosend+0x62b
> soo_write(c1c5c264,d0a44c84,c1b0f680,0,c177e190) at soo_write+0x49
> dofilewrite(5,8081000,a0,ffffffff,ffffffff) at dofilewrite+0xac
> write(c177e190,d0a44d14,c,431,3) at write+0x77
> syscall(2f,2f,2f,8071d88,a0) at syscall+0x137
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (4, FreeBSD ELF32, write), eip = 0x282ef73f, esp = 0xbfbfddfc,
> ebp =0xbfbfde18 ---
>
> Tell me how I can help, I'll later hand in the trace of the slef-lock when
> debug.mpsafenet is 1.

Do you have pfsync compiled in?  Is it up?  If that's the case, can you try 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.  Tell me if 
removeing it helps.  Thanks.

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.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pfassert.diff
Type: text/x-diff
Size: 875 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050208/8055fab3/pfassert.bin
-------------- 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/8055fab3/attachment.bin