The following reply was made to PR kern/154676; it has been noted by GNATS.

From: "Sergey V. Dyatko" <sergey.dya...@gmail.com>
To: =?ISO-8859-1?Q?Andr=E9?= Oppermann <an...@freebsd.org>
Cc: Arnaud Lacombe <lacom...@gmail.com>, bug-follo...@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 <lacom...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to