[Bug 264257] [tcp] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 24 Jun 2022 14:35:21 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257

--- Comment #74 from Richard Scheffenegger <rscheff@freebsd.org> ---
The offending TCP sessions we've seen so far all seem to be regular https
sessions. For (yet unknown) reasons, rarely the FIN bit seems to get accounted
more than once - up to 6 times, from one of the logging patched kernels.

With SACK rescue retransmissions, that can lead to having the sequence number
of one or more FIN bits included in the block which is to be retransmitted -
and the panic happens, when the data byte at the sequence number of the FIN bit
is tried to be retranmitted...

In your case, even though you didn't have SACK rescue retransmissions enabled,
the client of the offending session appears to have SACK'ed the 2nd
retransmission of the (and empty) FIN packet with a "too high" sequence number,
in effect resulting in the same issue. This should be happening much less
frequently than with the SACK rescue retransmissions.

At the same time, it appears, that double-counting of FIN bits happens quite
frequently, but is not easy to reproduce. Thus we are currently working on a
patch which exposes this (in INVARIANTS kernels with panics, in production
kernels by logging that unexpected state, and clearing it "on the fly").

See D35446

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.