Subject: Re: purpose of mbuf type MT_HEADER (see pr kern/24713)
To: None <>
From: Ignatios Souvatzis <>
List: tech-net
Date: 10/04/2004 22:08:58
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


> Could please somebody look at kern/26937 and confirm (or disprove) it?

I propose to remove the test for the time being, (one line code change
plus one line comment change) and pull up to the release branch.

The case caught which panics in 26973 (MT_DATA vs. MT_PKTHDR) is only
very vaguely described in the mbuf documentation, be it online or in the
literature, and it doesn't surprise me that more cases of this type
difference are found; half of the test (introduced in 1.72 of uipc_mbuf.c
I think) was already removed on the 1.78 to remove a similar panic for

(Maybe this test can be reintroduced in the future, but only after
writing a policy on type usage, and closely inspecting all mbuf uses
and fixing them to comply with the policy...)

	Ignatios Souvatzis

marie kern !% cvs diff -u uipc_mbuf.c
Index: uipc_mbuf.c
RCS file: /cvsroot/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.88
diff -u -r1.88 uipc_mbuf.c
--- uipc_mbuf.c 17 Sep 2004 23:24:03 -0000      1.88
+++ uipc_mbuf.c 4 Oct 2004 20:10:52 -0000
@@ -696,7 +696,6 @@
  * Concatenate mbuf chain n to m.
  * n might be copied into m (when n->m_len is small), therefore data porti=
on of
  * n could be copied into an mbuf of different mbuf type.
- * Therefore both chains should be of the same type (e.g. MT_DATA).
  * Any m_pkthdr is not updated.
@@ -711,7 +710,6 @@
                        m->m_next =3D n;
-               KASSERT(n->m_len =3D=3D 0 || m->m_type =3D=3D n->m_type);
                /* splat the data from one into the other */
                memcpy(mtod(m, caddr_t) + m->m_len, mtod(n, caddr_t),

seal your e-mail:

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)