sb_mbtail is not set in sbappendrecord_locked()

From: Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com>
Date: Sun, 19 Apr 2009 16:06:51 -0700
hello,

i'm fairly certain that sbappendrecord_locked() has bug in it. the bug
is triggered by the kernel SOCKBUF_DEBUG option. the easiest way to
trigger the bug is to

1) compile kernel with the SOCKBUF_DEBUG option enabled;

2) call sbappendrecord_locked() and try to append mbuf chain with
exactly one mbuf (i.e. m0->m_next is NULL) to an empty sockbuf;

there is a kern/126742 pr that basically shows the problem and stack traces.

initial investigation was done by "pluknet" < pluknet -at- gmail -dot-
com >, who confirmed the bug. see
http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019345.html
for more details.

i'm proposing the following patch. please review.

==

> svn diff
Index: uipc_sockbuf.c
===================================================================
--- uipc_sockbuf.c      (revision 191012)
+++ uipc_sockbuf.c      (working copy)
_at__at_ -577,10 +577,6 _at__at_

      if (m0 == 0)
              return;
-       m = sb->sb_mb;
-       if (m)
-               while (m->m_nextpkt)
-                       m = m->m_nextpkt;
      /*
       * Put the first mbuf on the queue.  Note this permits zero length
       * records.
_at__at_ -588,17 +584,17 _at__at_
      sballoc(sb, m0);
      SBLASTRECORDCHK(sb);
      SBLINKRECORD(sb, m0);
-       if (m)
-               m->m_nextpkt = m0;
-       else
-               sb->sb_mb = m0;
+       sb->sb_mbtail = m0;
      m = m0->m_next;
      m0->m_next = 0;
-       if (m && (m0->m_flags & M_EOR)) {
-               m0->m_flags &= ~M_EOR;
-               m->m_flags |= M_EOR;
+       if (m != NULL) {
+               if (m0->m_flags & M_EOR) {
+                       m0->m_flags &= ~M_EOR;
+                       m->m_flags |= M_EOR;
+               }
+
+               sbcompress(sb, m, m0);
      }
-       sbcompress(sb, m, m0);
 }

 /*

==

thanks,
max
Received on Sun Apr 19 2009 - 21:06:53 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:46 UTC