7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo
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:
> 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!
More information about the freebsd-stable