Date: Thu, 25 Feb 2021 15:33:14 +0000 From: bugzilla-noreply@freebsd.org To: transport@FreeBSD.org Subject: [Bug 253848] panic: sackhint bytes rtx >= 0 Message-ID: <bug-253848-38102-ORXhHkCPqd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253848-38102@https.bugs.freebsd.org/bugzilla/> References: <bug-253848-38102@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253848 --- Comment #1 from Richard Scheffenegger <rscheff@freebsd.org> --- Hi Andriy, I guess I am currently the person who has the most recent knowledge about t= hat 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 t= hat 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 recent= ly (but the sackhint struct was changed recently, and other/additional scorebo= ard accounting was added). (kgdb) p *cur $1 =3D {start =3D 3846347980, end =3D 3846352300, rxmit =3D 3846352300, scb= link =3D {tqe_next =3D 0xfffff8013da5a220, tqe_prev =3D 0xfffff80754818930}} This indicates, that the current hole in the SACK scoreboard (3 segments of size 1440 bytes) were retransmitted (rxmit =3D=3D end), before the current acknowledgement came back. Thus the expectation is, that sackhint.sack_bytes_rexmit also has a value o= f 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 =3D -1440 Indicating negative one packet had been retransmitted before (thus subtract= ing the hole, which was previously retransmitted violates the invariant). And t= he 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 ne= ver 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... --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253848-38102-ORXhHkCPqd>