I think I've come across a small bug in ALTQ. It doesn't seem to be
triggered during normal operation, I found it when extending ALTQ to handle
inbound processing. (Which is coming along nicely, by the way.)
The problem is that _addq() and _getq() do not clear the m_nextpkt pointer.
This causes all kinds of panics when such mbufs end up in other queues
which also chain mbufs using that pointer (e.g. socket buffers). Again,
this isn't a problem normally, since ALTQ isn't used for inbound
processing.
The two patches below fix the problem, maybe you'd like to apply them to
the CVS tree anyway:
Index: altq/altq_classq.h
===================================================================
RCS file: /home/xbone/CVSROOT/kame/kame/sys/altq/altq_classq.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 altq_classq.h
--- altq/altq_classq.h 2001/01/24 20:05:27 1.1.1.1
+++ altq/altq_classq.h 2001/02/06 20:33:22
@@ -95,8 +95,10 @@
if ((m0 = qtail(q)) != NULL)
m->m_nextpkt = m0->m_nextpkt;
- else
+ else {
+ m->m_nextpkt = NULL;
m0 = m;
+ }
m0->m_nextpkt = m;
qtail(q) = m;
qlen(q)++;
@@ -114,6 +116,7 @@
else
qtail(q) = NULL;
qlen(q)--;
+ m->m_nextpkt = NULL;
return (m0);
}
Index: altq/altq_rmclass.c
===================================================================
RCS file: /home/xbone/CVSROOT/kame/kame/sys/altq/altq_rmclass.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 altq_rmclass.c
--- altq/altq_rmclass.c 2001/01/24 20:05:28 1.1.1.1
+++ altq/altq_rmclass.c 2001/02/06 20:32:48
@@ -1758,8 +1758,10 @@
if ((m0 = qtail(q)) != NULL)
m->m_nextpkt = m0->m_nextpkt;
- else
+ else {
+ m->m_nextpkt = NULL;
m0 = m;
+ }
m0->m_nextpkt = m;
qtail(q) = m;
qlen(q)++;
@@ -1780,6 +1782,7 @@
qtail(q) = NULL;
}
qlen(q)--;
+ m0->m_nextpkt = NULL;
return (m0);
}
--
Lars Eggert <larse@isi.edu> Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature