https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288904
--- Comment #25 from [email protected] ---
(In reply to Gleb Smirnoff from comment #11)
Looks like it is PR 276761 (tcp_close() vs tcp_discardcb() timers desync). And
yes, it was not MFCed to 14.x. The commit
bffebc336f4ece4d18774c1ab8f555802cebf961 is related because it fixes a race
introduced by PR 276761 fix, but it is not a direct source of these panics.
I made a small patch which is expected to fix the problem in 14.x branch. Did
not tested it much for now.
I don't think it is a good idea to keep supported 14.4 release in unusable
state.
--- sys/netinet/tcp_subr.c.orig 2026-08-01 23:05:43.997108869 +0300
+++ sys/netinet/tcp_subr.c 2026-08-05 11:51:31.431921701 +0300
@@ -2598,6 +2598,16 @@
tcp_fastopen_decrement_counter(tp->t_tfo_pending);
tp->t_tfo_pending = NULL;
}
+
+ /*
+ * tcp_timer_stop() may drop INP_WLOCK internally
+ * this may lead to racy two-thread closing in rare cases
+ * so just reset tp->t_timers
+ * tcp_timer_enter() is aware of this
+ */
+ for (tt_which i = 0; i < TT_N; i++)
+ tp->t_timers[i] = SBT_MAX;
+
if (tp->t_fb->tfb_tcp_timer_stop_all != NULL)
tp->t_fb->tfb_tcp_timer_stop_all(tp);
in_pcbdrop(inp);
--- sys/netinet/tcp_timer.c.orig 2026-08-01 23:05:44.001110870 +0300
+++ sys/netinet/tcp_timer.c 2026-08-05 12:17:39.251384522 +0300
@@ -874,6 +874,11 @@
curthread->td_pflags |= TDP_INTCPCALLOUT;
which = tcp_timer_next(tp, NULL);
+ if (which == TT_N) { /* see tcp_close() comment about stoping timers */
+ INP_WUNLOCK(inp);
+ curthread->td_pflags &= ~TDP_INTCPCALLOUT;
+ return;
+ }
MPASS(which < TT_N);
tp->t_timers[which] = SBT_MAX;
tp->t_precisions[which] = 0;
@@ -909,6 +914,10 @@
#endif
INP_WLOCK_ASSERT(inp);
+ if (tp->t_state == TCPS_CLOSED) {
+/* printf("tcp_timer_activate(%p,%d,%u) for TCPS_CLOSED
connection, ignoring\n", tp, (int)which, delta);*/
+ return;
+ }
if (delta > 0) {
what = TT_STARTING;
The commented printf() will often print this warnings for TT_REXMT (0) if
enabled, but I don't think these silently skipped timer activations will harm
(they seems fixed in 15.x in some other place).
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.