Date: Thu, 07 Sep 2023 14:29:56 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273615] infinite loop in sbflush_internal() Message-ID: <bug-273615-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273615 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=3D244698&action= =3Dedit patch to prevent infinite loop in sbflush_internal() If I run iperf3 in a loop over a 100gbe network (via cxgbe) eventually eith= er 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.=20 sb->sb_ccc is cast to an int and passed into sbcut_internal(), which then f= ails to consume the data and returns NULL. sbflush_internal() then keeps retryi= ng 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 t= his 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 t= hat 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 wh= en 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273615-227>