Re: mbuf_outbound_finalize and in_delayed_cksum_offset
Re: mbuf_outbound_finalize and in_delayed_cksum_offset
- Subject: Re: mbuf_outbound_finalize and in_delayed_cksum_offset
- From: Anton Kuzmin <email@hidden>
- Date: Tue, 27 Sep 2005 10:54:15 +0100
So that's what that top loop's supposed to do! I guess it's purpose was
a bit obscured by the fact the it compared "offset > m_len" and not
"offset >= m_len" as it probably should have been.
Did you include "printf(ip->ip_p)" bug as well in your radar or should I
do it?
Anton
The assumption that this code in the kernel makes is that the IP
header will be contiguous in one mbuf. It doesn't matter how many
mbufs are required for the entire packet, it just matters that the IP
header is contiguous in one of those mbufs.
If there is a 14 byte mbuf in the chain that only contains the
ethernet header, that mbuf will be skipped in the while loop that
appears just before this check. It looks like there is a flaw in that
loop though. I've filed a radar.
-josh
On Sep 26, 2005, at 7:03 AM, Anton Kuzmin wrote:
Our interface filter needs to call mbuf_outbound_finalize on
outgoing packets before performing some additional filtering, and
while debugging a kernel panic related to this I noticed a strange
comment in in_delayed_cksum_offset (called by mbuf_outbound_finalize):
...
if (ip_offset + sizeof(struct ip) > m->m_len) {
printf("delayed m_pullup, m->len: %d off: %d p: %d\n",
m->m_len, ip_offset, ip->ip_p);
/*
* XXX
* this shouldn't happen
*/
m = m_pullup(m, ip_offset + sizeof(struct ip));
}
...
and the following truly never happens, as "ip" used in printf(ip-
>ip_p) is not initialized at that point and the kernel panics,
although I don't think that was the original meaning of the comment.
But putting this aside (I'll do a bug report on this), what is the
reason not to expect a packet split in a chain of mbufs (and too
short first mbuf as a result) as I'm definitely seeing them in the
output function of the interface filter (i.e. some multicast mdns
packets, first mbuf is 14 bytes long and contains just the ethernet
header)?
Or is it just a case of not taking into account that
in_delayed_cksum_offset can now be called from the outbound
interface filter path?
Anton
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden