FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=stable%2F13 2024-01-06T01:15:23Z 2024-01-06T01:15:23Z Marius Strobl marius@FreeBSD.org 2023-08-22T18:12:59Z urn:sha1:1d15c4548576763843ea7268e494bf6015758ef8 This change adds struct tcp_info fields corresponding to the following struct tcpcb ones: - snd_una - snd_max - rcv_numsacks - rcv_adv - dupacks Note that while both tcp_fill_info() and fill_tcp_info_from_tcb() are extended accordingly, no counterpart of rcv_numsacks is available in the cxgbe(4) TOE PCB, though. Sponsored by: NetApp, Inc. (originally) (cherry picked from commit dc485b968ddeb070d23354f55164a8c336acf081) Conflicts (due tue missing 945f9a7c): sys/netinet/tcp.h 2024-01-05T22:48:34Z Marius Strobl marius@FreeBSD.org 2023-08-22T17:03:42Z urn:sha1:bc85442bf6c9effcea7d7ef24651998b35c04dc9 This function actually only ever reads from the TCP PCB. Consequently, also make the pointer to its TCP PCB parameter const. Sponsored by: NetApp, Inc. (originally) (cherry picked from commit 8c6104c48ea3f0ffaabeb9784b0f2327db04e7af) Conflicts (due tue missing 9eb0e832): sys/dev/cxgbe/tom/t4_tom.c sys/netinet/tcp_offload.c sys/netinet/tcp_usrreq.c 2023-08-23T17:43:25Z Warner Losh imp@FreeBSD.org 2023-08-22T01:31:27Z urn:sha1:3bc80996974a61a4223eae4c1ccd47b6ee32a48a Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ Similar commit in current: (cherry picked from commit 685dc743dc3b) 2023-03-02T07:36:21Z Richard Scheffenegger rscheff@FreeBSD.org 2023-02-28T18:57:30Z urn:sha1:2be7e3df72758f46c853c08cd4e35f4e5fb0b187 Reviewed By: tuexen, cc, #transport MFC after: 3 days Sponsored by: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D38824 (cherry picked from commit 399a5655e6edf69a63f1c37e66fdad19dcfdb5cf) 2023-02-02T00:02:30Z Michael Tuexen tuexen@FreeBSD.org 2022-11-16T10:22:13Z urn:sha1:e97522a1b7ea023961d604221eb38960fd170fa9 No functional change intended. Reviewed by: rscheff@ Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D37401 (cherry picked from commit bd4f986644b3804e19b92d39f1f90ffabff83e14) 2022-09-19T15:49:55Z Gleb Smirnoff glebius@FreeBSD.org 2022-09-05T17:15:19Z urn:sha1:0d0c1ffcf4fc6d382887e89c5d8b0b7a270d0689 PR: 262663 Reported & tested by: dch (cherry picked from commit 0773b44e829421a806a89087009b294f16ee51fd) 2022-07-20T15:24:49Z Claudio Jeker claudio@openbsd.org 2022-06-23T14:50:47Z urn:sha1:dc2e12abb22a303aed88c6dd042d652cab8a2bad Unlock the inp when hanlding TCP_MD5SIG socket options. tcp_ipsec_pcbctl handles locking the inp when the option is being modified. This was found by Claudio Jeker while working on the OpenBGPd port. On 14 we get a panic when trying to call getsockopt, on 13.1 the process locks up using 100% CPU. Reviewed by: rscheff (transport), tuexen MFC after: 3 days Sponsored by: Klara Inc. Differential Revision: https://reviews.freebsd.org/D35532 (cherry picked from commit 97453e5e7258158042795740f2736cfca972269d) 2022-02-22T22:27:01Z Michael Tuexen tuexen@FreeBSD.org 2021-08-05T11:42:30Z urn:sha1:db8fc0ef23d14cd281e019ee3a15b1a15931237d Reported by: syzbot+24fcfd8057e9bc339295@syzkaller.appspotmail.com Reported by: syzbot+6e90ceb5c89285b2655b@syzkaller.appspotmail.com Reviewed by: markj, rscheff Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D31422 (cherry picked from commit 3f1f6b6ef7f6fea63583a4b6e917b3cc0f0d525e) 2021-07-13T19:54:43Z Andrew Gallatin gallatin@FreeBSD.org 2021-05-25T17:45:37Z urn:sha1:1843b06deeb22ae5990d5a0308bebaad1bd27e98 We need to enter the network epoch when calling into tfb_tcp_fb_fini. I noticed this when I hit an assert running the latest rack Differential Revision: https://reviews.freebsd.org/D30407 Reviewed by: rrs, tuexen Sponsored by: Netflix (cherry picked from commit 086a35562f47917a516d30acc8b78a4884e31a4f) 2021-06-09T00:19:47Z Randall Stewart rrs@FreeBSD.org 2021-06-04T09:26:43Z urn:sha1:fc53b7269fedf53b5fb13e4587d017d6bd833cf3 So it turns out that my fix before was not correct. It ended with us failing some of the "improved" SYN tests, since we are not in the correct states. With more digging I have figured out the root of the problem is that when we receive a SYN|FIN the reassembly code made it so we create a segq entry to hold the FIN. In the established state where we were not in order this would be correct i.e. a 0 len with a FIN would need to be accepted. But if you are in a front state we need to strip the FIN so we correctly handle the ACK but ignore the FIN. This gets us into the proper states and avoids the previous ack war. I back out some of the previous changes but then add a new change here in tcp_reass() that fixes the root cause of the issue. We still leave the rack panic fixes in place however. Reviewed by: mtuexen Sponsored by: Netflix Inc Differential Revision: https://reviews.freebsd.org/D30627 (cherry picked from commit 4747500deaaa7765ba1c0413197c23ddba4faf49)