[Bug 273615] infinite loop in sbflush_internal()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273615

            Bug ID: 273615
           Summary: infinite loop in sbflush_internal()
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: greg@codeconcepts.com

Created attachment 244698
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244698&action=edit
patch to prevent infinite loop in sbflush_internal()

If I run iperf3 in a loop over a 100gbe network (via cxgbe) eventually either
the client or server gets stuck in sbflush_internal().  This is because
sb->sb_ccc is an unsigned int that contains a value greater than INT_MAX. 
sb->sb_ccc is cast to an int and passed into sbcut_internal(), which then fails
to consume the data and returns NULL.  sbflush_internal() then keeps retrying
the operation having made no progress.

There is a KASSERT in sbcut_internal() to catch this, but I'm not able to
reproduce the problem with INVARIANTS enabled.  See commit
b5b023b91eee30bacb28684c7aa467bf547f7c0d for additional information about this
problem.

Note that I haven't yet been able to reproduce this on a 10gbe network.

I've attached a patch which addresses the immediate problem, but it seems that
given the mixed usage of ssize_t, u_int, and int by callers of sbflush() and
related interfaces that a larger scoped cleanup is desirable.  Note that when
the bug arises, sb_ccc is always around 3.1-billion, which makes me wonder if
my patch is merely a bandaid for a symptom of a deeper problem... ???

Here's the iperf3 loop I use to catch the problem:

while : ; do sudo iperf3 -c 172.16.10.200 --bidir || break; sleep 1; done

-- 
You are receiving this mail because:
You are the assignee for the bug.