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: Josh Graessley <email@hidden>
- Date: Tue, 27 Sep 2005 11:11:43 -0700
I don't believe that printing ip->ip_p is a bug. The printf is only
informational and should only appear when there is a bug in the
kernel or a kernel extension. ip->ip_p is defined when
mbuf_outbound_finalize is called from the interface layer.
-josh
On Sep 27, 2005, at 2:54 AM, Anton Kuzmin wrote:
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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