Summary: | [tcp] frequent panics in tcp_output | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Ivan Rozhuk <rozhuk.im> | ||||||
Component: | kern | Assignee: | Richard Scheffenegger <rscheff> | ||||||
Status: | Closed FIXED | ||||||||
Severity: | Affects Only Me | CC: | ae, cy, hselasky, rozhuk.im, rscheff, thj, tuexen | ||||||
Priority: | --- | Keywords: | crash | ||||||
Version: | 13.0-STABLE | ||||||||
Hardware: | amd64 | ||||||||
OS: | Any | ||||||||
See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254244 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263445 |
||||||||
Attachments: |
|
Description
Ivan Rozhuk
2021-03-15 15:41:50 UTC
Can you include more information about your FreeBSD version (git hash), tcp configuration (congestion control, tcp stack) and maybe comment on what your workload is and when the panics are triggered? It would be great to see the panic message and to have a way to reproduce it. Can you describe how to reproduce the issue? Does the same problem occur when you are using CURRENT? Created attachment 223295 [details] crash log http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/usr/src/sys/amd64/conf/ srv+base http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/etc/sysctl.conf Other configs available: http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/ base+srv This is home NAS+++ server, with web server, samba, rtorrent, etc that connected to inet via IPv4 + IPv6. This happen few times, once per day. I can not reproduce this. FreeBSD 13 amd64, few days old sources build. Created attachment 223296 [details]
log 2
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether *********** media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=9<PERFORMNUD,IFDISABLED> Got first crash (@m_copydata (m=0x0, m@entry=0xfffff80576236400, off=0, len=1, cp=<optimized out>) at /usr/src/sys/kern/uipc_mbuf.c:656) on 2 different installations. Suspect that it caused by some changes in last 1-2 month or by me: I add options RATELIMIT #o TX rate limiting support #10 0xffffffff8076ec3a in tcp_output (tp=0xfffffe01137c60c0) at /usr/src/sys/netinet/tcp_output.c:1068 1068 m_copydata(mb, moff, len, (kgdb) info locals moff = 0 mb = 0xfffff802a20ba800 msb = <optimized out> opt = "\001\001\b\n\325\035\060\267+\223/\264\001\376\377\377\001M\373\267\000\000\000\000\340`|\023\001\376\377\377\250\005\000\000\000\000\000" to = {to_flags = 16, to_tsval = 3073383893, to_tsecr = 3023016747, to_sacks = 0xfffffe001eacac00 "\300P\254\036", to_signature = 0x11ea8d0c0 <error: Cannot access memory at address 0x11ea8d0c0>, to_tfo_cookie = 0xfe <error: Cannot access memory at address 0xfe>, to_mss = 8288, to_wscale = 229 '\345', to_nsacks = 197 '\305', to_tfo_len = 0 '\000', to_spare = 3535675904} hw_tls = false isipv6 = <optimized out> ip6 = 0x0 dont_sendalot = 0 wanted_cookie = 0 ip = 0xfffff8020e774668 if_hw_tsomaxsegsize = 0 if_hw_tsomaxsegcount = 0 error = <optimized out> so = <optimized out> idle = 0 sendalot = 1 tso = 0 flags = 17 recwin = 2098020 sack_rxmit = 1 p = 0xfffff802a256ef20 off = 32622 mtu = 0 sendwin = <optimized out> sack_bytes_rxmt = <optimized out> len = 1 ipoptlen = <optimized out> optlen = <optimized out> hdrlen = <optimized out> curticks = <optimized out> m = 0xfffff8020eecec00 th = <optimized out> I try kernel without: options RATELIMIT #o TX rate limiting support options TCP_OFFLOAD #o TCP offload options TCP_BLACKBOX #o Enhanced TCP event logging options TCP_HHOOK #o hhook(9) framework for TCP options TCP_RFC7413 #o Server-side implementation of TCP Fast Open (TFO) [RFC7413] options TCP_RFC7413_MAX_KEYS=2 #o options TCPHPTS #o high precision timer system for tcp. not help. Hi, Try to set: sysctl net.inet.tcp.sack.enable=0 For now. --HPS Better, disable net.inet.tcp.rfc6675_pipe=0 while retaining SACK. See https://reviews.freebsd.org/D29315 flags = 17 -> 0x11, 0x10 is TF_SENTFIN, TF_ACKNOW and 6675pipe is enabled, enabling the new rescue-retransmission. Further, this is stated to be a web server, where it is likely that http/1.0 tcp sessions are closed right after an object was sent, and if the very last segment with the FIN is dropped by the network, the rescue retransmission code tried to include the "data byte" of the FIN (which doesn't exist really, only as the last octet in the sequence space stream). A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e9f029831fa5747ae1b405f5716c52cb4ebf1e04 commit e9f029831fa5747ae1b405f5716c52cb4ebf1e04 Author: Richard Scheffenegger <rscheff@FreeBSD.org> AuthorDate: 2021-03-17 15:44:29 +0000 Commit: Richard Scheffenegger <rscheff@FreeBSD.org> CommitDate: 2021-03-17 16:12:04 +0000 fix panic when rescue retransmission and FIN overlap PR: 254244 PR: 254309 Reviewed By: #transport, hselasky, tuexen MFC after: 3 days Sponsored By: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D29315 sys/netinet/tcp_sack.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=703419774f86525a2441d615733993a6fddcd047 commit 703419774f86525a2441d615733993a6fddcd047 Author: Richard Scheffenegger <rscheff@FreeBSD.org> AuthorDate: 2021-03-17 15:44:29 +0000 Commit: Richard Scheffenegger <rscheff@FreeBSD.org> CommitDate: 2021-03-17 19:05:33 +0000 fix panic when rescue retransmission and FIN overlap PR: 254244 PR: 254309 Reviewed By: #transport, hselasky, tuexen Approved by: re (cperciva) MFC after: immediately Sponsored By: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D29315 (cherry picked from commit e9f029831fa5747ae1b405f5716c52cb4ebf1e04) sys/netinet/tcp_sack.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) 2 days uptime without panic, looks like fixed. Thanks! |