The following reply was made to PR kern/154676; it has been noted by GNATS.
From: Arnaud Lacombe <lacom...@gmail.com>
To: bug-follo...@freebsd.org, sergey.dya...@gmail.com,
=?ISO-8859-1?Q?Andr=E9_Oppermann?= <an...@freebsd.org>
Cc:
Subject: [debugged] Re: kern/154676: [netgraph] [panic] HEAD, 8.1-RELEASE
panic after some play with netgraph
Date: Sun, 13 Feb 2011 04:29:58 -0500
[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.
_______________________________________________
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"
