Date: Fri, 03 Jun 2022 09:18:55 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 264428] [tcp] Crash in sbsndptr Message-ID: <bug-264428-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264428 Bug ID: 264428 Summary: [tcp] Crash in sbsndptr Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: ram.gupta.19@gmail.com Following is the analysis of the crash seen in sbsndptr in the stack.=20 #0 0x0000ffff8ead225c in raise () from /usr/lib/libc.so.6 #1 0x0000ffff8ead3310 in abort () from /usr/lib/libc.so.6 #2 0x000000000097b238 in panic (fmt=3Dfmt@entry=3D0xb7b9e0 "%s: sockbuf %p= and mbuf %p clashing") at uinet_kern_shutdown.c:48 #3 0x0000000000915df4 in sbsndptr (sb=3Dsb@entry=3D0x40003fff5188, off=3D<= optimized out>, off@entry=3D462, len=3Dlen@entry=3D462, moff=3Dmoff@entry=3D0xffff79eb64c8) at /root/open_source/uinet/sys/kern/uipc_sockbuf.c:1025 #4 0x0000000000963d24 in tcp_output (tp=3Dtp@entry=3D0x40003ffed000) at /root/open_source/uinet/sys/netinet/tcp_output.c:873 #5 0x0000000000970994 in tcp_output_send (tp=3D0x40003ffed000) at /root/open_source/uinet/sys/netinet/tcp_offload.h:282 #6 tcp_usr_send (so=3D0x40003fff5000, flags=3D0, m=3D<optimized out>, nam= =3D0x0, control=3D<optimized out>, td=3D0xffff79ebb280) at /root/open_source/uinet/sys/netinet/tcp_usrreq.c:887 #7 0x00000000009185dc in sosend_generic (so=3D0x40003fff5000, addr=3D0xffff00000001, uio=3D0xffff79eb65f8, top=3D0x40003fd72000, control= =3D0x1ce, flags=3D0, td=3D0xffff79eb65b0) at /root/open_source/uinet/sys/kern/uipc_socket.c:1528 #8 0x00000000009187a0 in sosend (so=3D<optimized out>, addr=3D<optimized o= ut>, uio=3Duio@entry=3D0xffff79eb6608, top=3Dtop@entry=3D0x0, control=3Dcontrol@entry=3D0x0, flags=3Dflags@entry=3D0, td=3D<optimized= out>) at /root/open_source/uinet/sys/kern/uipc_socket.c:1574 The issue happens when trailing space becomes less than segment size. . Thi= s is where the problem starts as below=20 1) Sbcompress instead of incrementing mbuf len, sets the input mbuf to= the sb->mb_tail next pointer.=20 2) It also calls sballoc where a new mbuf is stored in the socket buf. This mbuf is stored in sb->sb_mb pointer of send sockbuf. 3) At this point, the len is 462B, offset is 462B and sb_cc is 924B (o= ne seg wating for ack and other to be sent) and sb_sndptroff is 462=20 4) When sbsndptr is called, it gets the new mbuf stored in step 2 which does not have m->next pointer at this point of time.=20 5) Offset calculated is (off - sb_sndptroff + len =E2=80=93 1) but si= nce m->next pointer is null, panic is caused.=20 Since the mbuf flag is not set to M_HOLE, Trailing space remains constant rather than increasing for accommodating new mbuf.=20 static void sbdrop_internal(struct sockbuf *sb, int len) { =E2=80=A6 if (m->m_len > len) { m->m_len -=3D len; -> Increase TS if (!(m->m_flags & M_HOLE)) { m->m_data +=3D len; -> Equalizes the TS=20 } Where TS is=20 (m)->m_ext.ext_buf + (m)->m_ext.ext_size - ((m)->m_data + (m)->m_len) So in nutshell, this condition hits in the following case where segment is being trying to be sent=20 1) TS shrinks to lower than m->m_len. (This condition is rare to happe= n if all acks for a particular mbuf are received at any point of time. If rcv=E2= =80=99ed, mbuf is freed and sockbuf mbuf pointer is null. This resets the TS from 204= 8)=20 2) Unacknowledged data is one ACK away (off will be 462)=20 3) Length to be sent (462B)=20 So the question is, on high pps environment, should m_flags be set to M_HOL= E so TS can adjust dynamically.=20 Thanks, Raman --=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-264428-227>