Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Feb 2024 10:25:11 +0000
From:      bugzilla-noreply@freebsd.org
To:        transport@FreeBSD.org
Subject:   [Bug 276761] panic: sbsndptr_noadv: sb_mb is NULL
Message-ID:  <bug-276761-38102-vhIPKt4BIT@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-276761-38102@https.bugs.freebsd.org/bugzilla/>
References:  <bug-276761-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=3D276761

--- Comment #13 from Richard Scheffenegger <rscheff@freebsd.org> ---
Just a summary of our findings:

Under rare circumstances, tcp_close() is called without being followed up
quickly - prior of any timer going off - by tcp_discardcb(). In tcp_close()=
 the
socket buffers are relinquished, but the clean up of associated state would
only be done later in tcp_discardcb().=20

The change exposing this was to no longer discard the SACK scoreboard
immediately with a Retransmission timeout, in order to avoid unneccessary
retransmissions in such an event. The SACK scoreboard is used for transmiss=
ion
selection during loss recovery or retransmission timeouts.

Additionally, timers could be restarted after having sent a RST packet from
tcp_drop() - while the session was already closed.

In summary, it appears that there always existed the problem of inconsistent
state in between tcp_close() and tcp_discardcb(), where a timer could trigg=
er.
However, as an RTO would previously clean the SACK scoreboard state, this w=
ould
not lead to external visible misbehavior or a panic.

The three commits address these issues individually
- clean any SACK state together with releasing the socket buffer
- stop re-arming any timers in the case of sending a RST (while in CLOSED
state)
- stop timers in tcp_close() instead of waiting for the final clean-up of t=
cpcb
state in tcp_discardcb().

--=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-276761-38102-vhIPKt4BIT>