From owner-freebsd-net@FreeBSD.ORG Tue Mar 15 08:40:18 2011 Return-Path: <owner-freebsd-net@FreeBSD.ORG> Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82DF10657A3 for <freebsd-net@hub.freebsd.org>; Tue, 15 Mar 2011 08:40:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 458DF8FC19 for <freebsd-net@hub.freebsd.org>; Tue, 15 Mar 2011 08:40:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2F8eI2i004725 for <freebsd-net@freefall.freebsd.org>; Tue, 15 Mar 2011 08:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2F8eI9U004724; Tue, 15 Mar 2011 08:40:18 GMT (envelope-from gnats) Date: Tue, 15 Mar 2011 08:40:18 GMT Message-Id: <201103150840.p2F8eI9U004724@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Sergey V. Dyatko" <sergey.dyatko@gmail.com> Cc: Subject: Re: [debugged] Re: kern/154676: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Sergey V. Dyatko" <sergey.dyatko@gmail.com> List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net> List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 08:40:18 -0000 The following reply was made to PR kern/154676; it has been noted by GNATS. From: "Sergey V. Dyatko" <sergey.dyatko@gmail.com> To: =?ISO-8859-1?Q?Andr=E9?= Oppermann <andre@FreeBSD.org> Cc: Arnaud Lacombe <lacombar@gmail.com>, bug-followup@FreeBSD.org Subject: Re: [debugged] Re: kern/154676: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph Date: Tue, 15 Mar 2011 10:23:12 +0200 On Sun, 13 Feb 2011 04:29:58 -0500 Arnaud Lacombe <lacombar@gmail.com> wrote: > [Adding andre@, see below] > > I think I narrowed this down to right after the call to > sbappendstream_locked() in netinet/tcp_input.c:tcp_do_segment(), line > 2713. On 7.1, the mbuf has its M_PKTHDR set. It is not set in > -current. However, the mbuf passed to tcp_do_segment() has the flag > set (enforced by M_ASSERTPKTHDR(m)), so it should have been lost > in-between. > > [...] > > ... of course ...sbappendstream_locked() of 7.1 has no call to > m_demote(). I suppose that ng_ksocket will work again if I remove the > call. > > [...] > > Yes it does... > > For the record, this call has been introduced in: > > commit ec3cce1383deb16282c3576cc3dc2f3bb1ba9375 > Author: andre <andre@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f> > Date: Mon Jun 22 21:46:40 2009 +0000 > > In sbappendstream_locked() demote all incoming packet mbufs (and > chains) to pure data mbufs using m_demote(). This removes the > packet header and all m_tag information as they are not meaningful > anymore on a stream socket where mbufs are linked through > m->m_next. Strictly speaking a packet header can be only ever valid > on the first mbuf in an m_next chain. > > sbcompress() was doing this already when the mbuf chain layout > lent itself to it (e.g. header splitting or merge-append), just not > consistently. > > This frees resources at socket buffer append time instead of at > sbdrop_internal() time after data has been read from the socket. > > For MAC the per packet information has done its duty and during > socket buffer appending the policy of the socket itself takes > over. With the append the packet boundaries disappear naturally and > with it any context that was based on it. None of the residual > information from mbuf headers in the socket buffer on stream sockets > was looked at. Andre, I'm ready to test a patch if you provide it -- wbr, tiger