Bug 253848
| Summary: | [tcp] panic: sackhint bytes rtx >= 0 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Richard Scheffenegger <rscheff> |
| Component: | kern | Assignee: | Richard Scheffenegger <rscheff> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | avg, transport, tuexen |
| Priority: | --- | ||
| Version: | 13.0-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Richard Scheffenegger
2021-02-25 15:31:12 UTC
Hi Andriy,
I guess I am currently the person who has the most recent knowledge about that part of the base stack...
Do you happen to have more (preceding) information about this, or a way to reproduce this?
Are you running any special stack (RACK, BBR) which may have switched back to the base stack in the middle of a loss recovery (I suspected at one point that this may cause issues, potentially)?
Or was something done with the ipfw that may have temporarily impacted a tcp session?
The accounting with sack_bytes_rexmit is rather old, and not touched recently (but the sackhint struct was changed recently, and other/additional scoreboard accounting was added).
(kgdb) p *cur
$1 = {start = 3846347980, end = 3846352300, rxmit = 3846352300, scblink = {tqe_next = 0xfffff8013da5a220, tqe_prev = 0xfffff80754818930}}
This indicates, that the current hole in the SACK scoreboard (3 segments of size 1440 bytes) were retransmitted (rxmit == end), before the current acknowledgement came back.
Thus the expectation is, that sackhint.sack_bytes_rexmit also has a value of at least that number of bytes (4320). It is increased in tcp_output() for each packet leaving while performing a retransmission.
But this is the peculiar part:
(kgdb) p tp@entry->sackhint.sack_bytes_rexmit<mailto:tp@entry-%3esackhint.sack_bytes_rexmit>
$3 = -1440
Indicating negative one packet had been retransmitted before (thus subtracting the hole, which was previously retransmitted violates the invariant). And the only piece of code decrementing it appears to be in tcp_output() during non-permanent error handling...
All updates to sackhint should be protected by the INPLOCK, so even if the rx and tx paths are running on different core, the sack_bytes_rexmit should never become negative.
The sack blocks returned indicate that (with snd.una as zero baseline, in segments) the client knows about segments 2..34 and 35..47.
The first hole has shrunk from the right (unusual; possible when two retransmissions were lost again, or the 3 segment originally sent, delayed by ~50 segments (unlikely).
Sorry to not being able to spot something obvious right away...
Some more peculiar observations: T_dupacks is 4 .. so this appears to be the 2nd ack, where we should be responding with more data to. At t_dupacks 3, SACK should have retransmitted only the first packet. However, the two holes (sackhint.nexthole for the final one, and *cur for the previous one, which we know is the first, as snd_una == cur->start ) both claim to have been retransmitted already (->rxmit == ->end), for a total of 4 segments... One change somewhat related to SACK loss recovery, which was added to stable/13, was PRR (D18892). Since early Dec, there was one reported instance of poor performance, and on closer inspection, there are a few possibilities, where unexpected negative values, or overflows can occur - but those "should" only expose themselves as packets either not sent when expected, or in larger bursts (3 instead of 2) packets, not a panic like you observed. There are a few diffs to improve that behavior, which I would like to MFC to stable/13 and 13.0 in the coming days: D28780 - harness to ensure PRR doesn't end with fully closed window (performance) D28813 - fix an overflow and errors due to mixup of "min"/"imin" (implicit typecast) (D28816) uncritical really, use updated pipe calculation D28819 - fix unintended double-accounting (D28822) enhanced heuristic, per standards-track draft of PRR I can not immediately see, how that may affect the sack_bytes_rexmit numbers, but PRR is one change in the loss recovery space added recently - so the panic may be somehow related. In todays #transport call, we discussed shortly about this. There may be a 2nd instance of this kind of panic, thus documenting it as a PR. Further, in order to allow the core to contain more information about past events (including TCP headers), if this happens in a reproducable way, the Blackbox Logging feature may sched more light as to how the variable ended up in this way. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4a8f3aad37dd35c905e34b64b022d60844ba8d01 commit 4a8f3aad37dd35c905e34b64b022d60844ba8d01 Author: Richard Scheffenegger <rscheff@FreeBSD.org> AuthorDate: 2021-03-05 16:45:23 +0000 Commit: Richard Scheffenegger <rscheff@FreeBSD.org> CommitDate: 2021-03-05 16:45:54 +0000 tcp: remove incorrect reset of SACK variable in PRR Reviewed By: #transport, rrs, tuexen PR: 253848 MFC after: 3 days Sponsored By: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D29083 sys/netinet/tcp_input.c | 1 - 1 file changed, 1 deletion(-) It turned out that only under a specific set of circumstances - RTO during a SACK loss recovery, while the client had not yet fully reported back all SACK blocks - a unnecessary initialization of sack_bytes_rexmit caused this panic. In mundane environments this was virtually not reproduceable, and even in exposed environments, tcp sessions apparently need to suffer from sudden RTT jumps / path changes to elicit the panic. Thanks to rrs@ and gallatin@ for helping by providing crucial timing and packet trace/tcp state information around a few occurances. A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d90bba73a2e43fa12ea19425d101df4c488c1070 commit d90bba73a2e43fa12ea19425d101df4c488c1070 Author: Richard Scheffenegger <rscheff@FreeBSD.org> AuthorDate: 2021-03-05 16:45:23 +0000 Commit: Richard Scheffenegger <rscheff@FreeBSD.org> CommitDate: 2021-03-08 10:43:49 +0000 tcp: remove incorrect reset of SACK variable in PRR Reviewed By: #transport, rrs, tuexen PR: 253848 MFC after: 3 days Sponsored By: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D29083 (cherry picked from commit 4a8f3aad37dd35c905e34b64b022d60844ba8d01) sys/netinet/tcp_input.c | 1 - 1 file changed, 1 deletion(-) A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bb60a68985c8902f4061f1e3338a74e5f7d36a5d commit bb60a68985c8902f4061f1e3338a74e5f7d36a5d Author: Richard Scheffenegger <rscheff@FreeBSD.org> AuthorDate: 2021-03-05 16:45:23 +0000 Commit: Richard Scheffenegger <rscheff@FreeBSD.org> CommitDate: 2021-03-08 14:17:12 +0000 tcp: remove incorrect reset of SACK variable in PRR tcp: Add prr_out in preparation for PRR/nonSACK and LRD Reviewed by: #transport, rrs, tuexen, kbowling Approved by: #re (gjb) PR: 253848 MFC after: 3 days Sponsored by: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D29083 Differential Revision: https://reviews.freebsd.org/D29058 (cherry picked from commit 4a8f3aad37dd35c905e34b64b022d60844ba8d01) (cherry picked from commit d90bba73a2e43fa12ea19425d101df4c488c1070) (cherry picked from commit e53138694aa41c24c17847afe959225ce0eeff91) (cherry picked from commit 71cc98ba735283b8720c9031eb87810f3d3d96a0) sys/netinet/tcp_input.c | 22 ++++++++-------------- sys/netinet/tcp_output.c | 8 ++++++++ sys/netinet/tcp_var.h | 2 +- 3 files changed, 17 insertions(+), 15 deletions(-) |