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

Florian Smeets flo at smeets.im
Tue Feb 2 14:59:12 UTC 2010


On 1/22/10 8:55 PM, Max Laier wrote:
> On Friday 22 January 2010 19:49:19 John Baldwin wrote:
>> On Friday 22 January 2010 12:18:20 pm Max Laier wrote:
>>>
>>> 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.
>
> What I meant to say was: if we return from the pfil hook we either report
> error (and/or consume the mbuf) or switch back to network byte order:
>
> http://fxr.watson.org/fxr/source/contrib/pf/net/pf_ioctl.c?v=FREEBSD72#L3655
>
> While I can't completely rule out that there is a double flip happening in
> some obscure path through pf, I very much doubt this is what is going on (or
> there would be more reports and it would happen straight away, not only after
> passing some data).  A quick search through the sources also didn't turn up
> any red flags.  All byte order operations inside pf are either temporary or
> performed on a properly copied packet that is send back through the stack
> (icmp error, tcp packet, ...).
>
> Depending on how easily this can be reproduced, my money is on modifying a
> shared mbuf (possibly inside enc(4)).
>

I have been running with a WITNESS kernel for 10 days now, and have 
tried quite a few things to reproduce the problem, but no luck so far.

I'll post again if i find something.

Thanks to everyone involved!

Cheers,
Florian


More information about the freebsd-stable mailing list