Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Apr 2021 22:12:17 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 254725] 13.0-RC4 crash tcp_lro
Message-ID:  <bug-254725-227-Brow6l7xuO@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-254725-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-254725-227@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=3D254725

--- Comment #10 from Richard Scheffenegger <rscheff@freebsd.org> ---
received the core and kernel.debug symbols.

The panic is likely a off-by-one related to the FIN bit, but not with the
rescue retransmission, but rather PRR.

The TCP state indicates, that only the last data byte, and the final FIN bit
are unacknowledged.=20

frame 11:
(kgdb) p *tp->sackhint.nexthole
$48 =3D {start =3D 935342315, end =3D 935342316, rxmit =3D 935342315, scbli=
nk =3D
{tqe_next =3D 0x0, tqe_prev =3D 0xfffffe013eac0618}}
(kgdb) p tp->snd_max
$49 =3D 935342317
(kgdb) p tp->snd_una
$50 =3D 935342315

(kgdb) p/x tp->t_flags
$6 =3D 0x603003f4  =3D=3D=3D=3D> TF_SENTFIN is set.

Now, the FIN bit occupys the last Seq# (..317).
The SACK hole should therefore be a valid 1 byte hole, which hasn't been
retransmitted...

The incoming SACK appears to be SACKing the FIN bit?

(kgdb) p/x *(struct sackblk *)to.to_sacks
$53 =3D {start =3D 0xec30c037, end =3D 0xed30c037}
(kgdb) p 0x37c030ec
$54 =3D 935342316
(kgdb) p 0x37c030ed
$55 =3D 935342317

--=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-254725-227-Brow6l7xuO>