Date: Tue, 02 Feb 2010 15:59:08 +0100 From: Florian Smeets <flo@smeets.im> To: Max Laier <max@love2party.net> Cc: Luigi Rizzo <luigi@freebsd.org>, Bjoern Zeeb <bz@freebsd.org>, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available Message-ID: <4B683DBC.1090604@smeets.im> In-Reply-To: <201001222055.45980.max@love2party.net> References: <4B58280C.50602@smeets.im> <201001221818.20409.max@love2party.net> <201001221349.19810.jhb@freebsd.org> <201001222055.45980.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B683DBC.1090604>