7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available

[John Baldwin]

On Friday 22 January 2010 12:18:20 pm Max Laier wrote:
> On Friday 22 January 2010 15:20:13 John Baldwin wrote:
> > On Friday 22 January 2010 3:08:45 am Florian Smeets wrote:
> ...
> > > If it really is IPsec traffic then there are no rewrite rules only 10 pf
> > > pass rules on the enc0 interface and a "scrub in all" rule.
> > >
> > > Perhaps it matters that i have these set:
> > >
> > > net.enc.out.ipsec_bpf_mask=0x00000001
> > > net.enc.out.ipsec_filter_mask=0x00000001
> > > net.enc.in.ipsec_bpf_mask=0x00000002
> > > net.enc.in.ipsec_filter_mask=0x00000002
> > >
> > > so that i can filter the "encapsulated" traffic.
> > 
> > I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they have
> > any ideas.
> 
> pf could be the culprit if it were present in the trace, but I don't see any 
> sign of it:
> 
> On Thursday 21 January 2010 11:10:20 Florian Smeets wrote:
> > #7  0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8
> > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030")
> >      at /usr/src/sys/kern/uipc_mbuf.c:815
> > #8  0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at
> > /usr/src/sys/netinet/ip_input.c:1307
> > #9  0xc05fa30c in ip_input (m=0xc23dc900) at
> > /usr/src/sys/netinet/ip_input.c:609
> > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at
> > /usr/src/sys/net/netisr.c:185
> > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at
> > /usr/src/sys/net/if_ethersubr.c:834
> > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at
> > /usr/src/sys/net/if_ethersubr.c:692
> > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at
> > /usr/src/sys/dev/sis/if_sis.c:1476
> > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at
> > /usr/src/sys/dev/sis/if_sis.c:1667
> > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at
> > /usr/src/sys/kern/kern_intr.c:1126
> > #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 <ithread_loop>,
> > arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811
> > #17 0xc06d9180 in fork_trampoline () at
> > /usr/src/sys/i386/i386/exception.s:271
> 
> pf does change the byte order in the pfil hook, but changes it back on return 
> to the stack either when returning from the hook or when calling back into the 
> stack.  There have been some issues where we missed returns to the stack that 
> would result in this situation, but since pf is not in the trace, this is 
> clearly not the case here.

That isn't necessarily the case.  ip_input() invokes the PFIL hooks which
then return after possibly modifying the packet.  The (possibly modified)
packet is then passed to ip_forward() from ip_input().  If the PFIL hook
modified the packet and returned ip_len in network byte order then it would
cause this breakage without showing up in the stack trace.

-- 
John Baldwin