From owner-freebsd-stable@FreeBSD.ORG Tue Feb 2 14:59:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EECC10656A5; Tue, 2 Feb 2010 14:59:12 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id 010638FC1B; Tue, 2 Feb 2010 14:59:11 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 1E1126218E; Tue, 2 Feb 2010 15:59:11 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YRZkeO80416y; Tue, 2 Feb 2010 15:59:08 +0100 (CET) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 9003462180; Tue, 2 Feb 2010 15:59:08 +0100 (CET) Message-ID: <4B683DBC.1090604@smeets.im> Date: Tue, 02 Feb 2010 15:59:08 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100131 Shredder/3.2a1pre MIME-Version: 1.0 To: Max Laier References: <4B58280C.50602@smeets.im> <201001221818.20409.max@love2party.net> <201001221349.19810.jhb@freebsd.org> <201001222055.45980.max@love2party.net> In-Reply-To: <201001222055.45980.max@love2party.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , Bjoern Zeeb , freebsd-stable@freebsd.org, John Baldwin Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 14:59:12 -0000 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